; Zimmer,
Vincent ; Schulz, Steffen ;
Tarral, Mathieu ; Morgan, Benoit
; Xu, Min ; Liu, Wei
Subject: Re: [edk2-devel] Question about UEFI, AddressSanitizer and MMU mappings
Hi Steven!
Good to know you already have something. I removed your LLVM Optimizations
suggestion that was about MPX
this month by some
> people’s fuzz test requirement. But I didn’t really test it. I would like
> to help if there is something wrong in it. Let me know.
>
>
>
>
>
> Thanks
>
> *Steven Shi*
>
>
>
>
>
> *From:* devel@edk2.groups.io * On Behalf Of *Ped
test it. I would like to help if
there is something wrong in it. Let me know.
Thanks
Steven Shi
From: devel@edk2.groups.io On Behalf Of Pedro Falcato
Sent: Saturday, March 26, 2022 4:48 AM
To: edk2-devel-groups-io ; Andrew Fish
Cc: Marvin Häuser
Subject: Re: [edk2-devel] Question
Hello,
I have some experience porting LLVM Sanitizers and am very interested in this
project coming live to UEFI as well. I had success with both entirely static
shadow memory allocation and dynamic on-demand allocation. For ASan in the UEFI
my personal idea would be trying to avoid page-fault
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
>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
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
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
