On Mon, 11 Apr 2022 at 19:35, Simon Glass sjg@chromium.org wrote:
Hi Andrew,
On Thu, 7 Apr 2022 at 03:41, Andrew Scull ascull@google.com wrote:
Add CONFIG_ASAN to build with the Address Sanitizer. This only works with the sandbox so the config is likewise dependent. The resulting executable will have ASAN instrumentation, including the leak detector that can be disabled with the ASAN_OPTIONS environment variable:
ASAN_OPTIONS=detect_leaks=0 ./u-boot
Since u-boot uses its own dlmalloc, dynamic allocations aren't automatically instrumented, but stack variables and globals are.
Instrumentation could be added to dlmalloc to poison and unpoison memory as it is allocated and deallocated, and to introduce redzones between allocations. Alternatively, the sandbox may be able to play games with the system allocator and somehow still keep the required memory abstraction. No effort to address dynamic allocation is made by this patch.
I have toyed with what to do here. I originally was thinking of using normal malloc() instead of dlmalloc() when running sandbox. But then of course it makes sandbox very diffferent from other archs, so it is not desirable. So I did not go down that path. Having said that, os_malloc() is used for some sandbox-specific things.
I would love to have an extra string parameter to malloc() which indicates what is doing the allocation (malloc_tag(size_t size, char *id)), so it is easier to see failures and get an annotated 'core dump'. But again, changing the alloc API is not so nice.
One weird thing to be aware of is that truetype fonts cause constant allocs and frees. It happens in the background but you'll notice it if you start tracing things.
Using the system allocator would give the nicest ASAN experience because a special allocator gets injected that tracks where allocations were made etc. so when a problem occurs it can point to the likely allocations automatically.
How did you go about keeping the memory model when using the system allocator?