Re: Question about UEFI, AddressSanitizer and MMU mappings

Andrew Fish

From an UEFI point of view if you own the memory you can do what you want with it. The UEFI Spec does not deal with paging but the PI Spec does have abstractions for how the CPU operates via the CPU ARCH Protocol [1].

So for example if you want to write protect the page tables, add guard page, or add a stack guard all that is OK and exists today [2].

Does Asan just need to force page faults? Or does it want to make virtual address mappings? 

If someone wants to work on ASan (or any of the other sanitizers) I’m happy to volunteer to consult. 


Andrew Fish

On Mar 25, 2022, at 2:07 AM, Marvin Häuser <mhaeuser@...> wrote:

Hey Pedro,

ASan is somewhat listed for „LLVM Optimizations“.
A quick and dirty reference for UEFI UBSan can be found here:

I don’t think you need to strictly adhere to the UEFI spec for debug tooling. I cannot check the code now, but I can imagine things like ConvertPointer() will not be happy about non-identity-mapping OOTB. But the issues I can think of should be fairly easy to resolve.

Best regards,

On 24. Mar 2022, at 23:32, Pedro Falcato <pedro.falcato@...> wrote:


I've been thinking about adding sanitizer support (UBSan and KASAN), like coreboot already has, to the wiki's Tasks for the upcoming GSoC, but I'm a bit confused by something.
Is there anything in the UEFI spec that stops us from doing non-identity memory mappings? I know it specifies the need for the identity mappings (in the architectures where it requires the MMU being enabled), but nowhere do I see anything about the other parts of the address space.
Of course, UEFI supporting AddressSanitizer would be kind of dependent on fancier memory mappings.


Join to automatically receive all group messages.