crashappsec / libcon4m

Base Compiler and Runtime Support for con4m
Apache License 2.0
0 stars 0 forks source link

.github/dev/meson: consider stricter/more helpful `ASAN_OPTIONS` / `UBSAN_OPTIONS` #64

Closed ee7 closed 4 months ago

ee7 commented 4 months ago

Not a high priority ticket - just for tracking/visibility.

E.g. as a diff to the workflow:

+        env:
+          ASAN_OPTIONS: '
+              abort_on_error=1
+              :check_initialization_order=1
+              :detect_invalid_pointer_pairs=1
+              :detect_stack_use_after_return=1
+              :fast_unwind_on_malloc=0
+              :print_scariness=1
+              :strict_init_order=1
+              :strict_string_checks=1
+            '
+          UBSAN_OPTIONS: 'print_stacktrace=1'

I tend to use approximately those options to make ASan more aggressive than the default, and to make UBSan output more useful.

viega commented 4 months ago

Due to the false positives when we scan the stack during GC, abort_on_error isn't a good one to set.

By the way, 80% of what this sanitizer does isn't going to be useful without us doing extra work.

This is because we almost never use malloc(); we mmap our own heaps in, with guard pages both before and after the allocation. So it won't have enough context to detect out-of-bounds writes but still within our heap, and anything that goes outside the bounds of the heap we are already going to be catching via mprotect.

It's still modestly useful for globals, and possibly useful for things passed on the stack.

The correct thing to do is to go through the effort of manually poisoning / unpoisoning the space between allocations via their API. I'm sure the next time I've got a clear memory scribble I'll end up doing the work; it isn't too hard.

viega commented 4 months ago

I think the recent work on custom checking obviates anything else w/ ASAN unless shown otherwise, considering this done.