wrote: >=20 > =EF=BB=BF > Hi! >=20 > 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. >=20 > Thanks, > Pedro >=20 --Apple-Mail-C437E7CE-2A69-4D2E-895A-AF275CAEAFEC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hey Pedro,

ASan is somewh= at listed for =E2=80=9ELLVM Optimizations=E2=80=9C.

A= quick and dirty reference for UEFI UBSan can be found here: https://github.com/acidanthera/OpenCorePkg/tree/master/Library/OcGuardL= ib

I don=E2=80=99t thi= nk 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 no= t be happy about non-identity-mapping OOTB. But the issues I can think of s= hould be fairly easy to resolve.

Best regards,

Marvin

<= br>

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

=EF=BB=BF
Hi!
I've been thinking about adding sanitizer support (UBSan and K= ASAN), 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 U= EFI spec that stops us from doing non-identity memory mappings? I know it s= pecifies the need for the identity mappings (in the architectures where it = requires the MMU being enabled), but nowhere do I see anything about the ot= her parts of the address space.
Of course, UEFI supporting Addres= sSanitizer would be kind of dependent on fancier memory mappings.
=

Thanks,
Pedro
=
=20

--Apple-Mail-C437E7CE-2A69-4D2E-895A-AF275CAEAFEC--