Should we use ASan ?

[sid-agrawal]

Given the recent bugs we have encountered related to buffer not being initialized and pointer errors, I was wondering if we will benefit from using something like https://github.com/google/sanitizers/wiki/AddressSanitizer in our code.

For now, even if we do not use it, let's use this thread to keep track of issues we find that could have been caught automatically using ASan.

We also need to check if our compiler has the option to enable ASan. gcc is supposed to have it.

@astevins @p-linh

[p-linh]

I think we should use this, and will look into figuring out how to enable it for our sel4-gpi module only.

[sid-agrawal]

This looks worth reading too
https://blog.gistre.epita.fr/posts/benjamin.peter-2022-10-28-address_sanitizer_internals/

[sid-agrawal]

Two things came to mind while reading this:

• We need a different version of malloc with the ASan hooks.
• ASan needs additional memory for the shadown memory. Does our elfloader need to be aware of that, or does it just load it like regular memory regions, and then the ASAN instrumentation uses it as needed?

[sid-agrawal]

For now, we shelved the idea as:

• We will need some new kernel(or kernel-like functionalities in userspace, given that we are in uKernel), and building those is not a priority.
• We will need to add hooks to malloc

Reading this seems more relevant to our usecase.
https://security.googleblog.com/2024/03/address-sanitizer-for-bare-metal.html