Andrew, Marvin,

Thanks for the quick responses.

I'll give you a rundown of asan/kasan: You create a big (16TB in PML5-less x86) virtual mapping for ASAN, each byte in the shadow map represents 8 bytes of address space, and you poison/unpoison memory as you go and allocate chunks of the address space (usually through malloc, but in our case, AllocatePool()/AllocatePages(), I imagine). Since the only thing you have is a large contiguous virtual mapping, you need to either take a page fault and create mappings on the address space as you go along (very possible in user-space, usually not possible in kernel space and I assume UEFI), or you need to do fun stuff w/ page tables; usually, this means that you set up some page tables pointing to a zero page and remap those same page tables all over the virtual mapping; after taking a look at all our available memory, we allocate shadow pages for those (so you can RW to them).

Note that going a different route (with some data structure instead of the big mapping) is possible but, if you do, you can't use the faster inline ASAN that clang/gcc can generate for you (which do these same memory accesses, but inlined instead of doing e.g call __asan_load_8).

So yeah, if SetMemoryAttributes is the only thing we have, we're going to need some support MMU code for each architecture.

Since adding AddressSanitizer support is pretty involved (build system + actual ASAN code + MMU support code for each arch), I feel like it would be a good large project for this year. I also feel tempted to throw UBSan into the mix and just call it "Add LLVM Sanitizer support to EDK2", but I don't know if that's too much for a GSoC student. Would love some feedback on this.

Note: I would like to work on this, but since I'll be a mentor this year I prefer to first see if a student is interested in this project.

Best regards,

Pedro

On Fri, Mar 25, 2022 at 6:42 PM Andrew Fish via groups.io <afish=apple.com@groups.io> wrote:

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].
PcdNullPointerDetectionPropertyMask
PcdInitValueInTempStack
PcdHeapGuardPageType
PcdHeapGuardPoolType
PcdHeapGuardPropertyMask
PcdHeapGuardPageType
PcdHeapGuardPropertyMask
PcdCpuStackGuard

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.

[1] https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Cpu.h#L221
[2] https://github.com/tianocore/edk2/blob/master/MdeModulePkg/MdeModulePkg.dec#L979

Thanks,

Andrew Fish

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

Hey Pedro,

ASan is somewhat listed for „LLVM Optimizations“.
A quick and dirty reference for UEFI UBSan can be found here: https://github.com/acidanthera/OpenCorePkg/tree/master/Library/OcGuardLib

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,
Marvin

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

Hi!

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.

Thanks,
Pedro