From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp14.apple.com (rn-mailsvcp-ppex-lapp14.apple.com [17.179.253.33]) by mx.groups.io with SMTP id smtpd.web09.534.1648233726380597223 for ; Fri, 25 Mar 2022 11:42:06 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=KjXthfxh; spf=pass (domain: apple.com, ip: 17.179.253.33, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp14.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp14.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 22PIfvPx027449; Fri, 25 Mar 2022 11:42:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=gCVzAgd3ofryju7wAAWSp600NEdwMzrMycFEQGGGY7I=; b=KjXthfxh7+9Sh7mMVlM+hFXQYpysLaE8OlnxKC3SO8DQA0FKC1cuEKMHrmTvD+dQq1rS gfD7XuJRwrx8L35V+MG4kg4cv4aJlPDRLqRcgntR+OuISr9TarMcH5K0jhO8mB7zAcZL bDlKn2i94ZcoFRIRLviATxfh6w2u0SNx8RIyv6n9NOeHixyRIJv3gWMld2/mwrQSUsho 7OumDmBQxC6ggzlhN1C8AM2i8VYc4XR0eFq0h963k+gH7V1IVzQtYGCbhKhWlUDkp6zb 5bT52JWsTBQ2yi3rHgmIEbPuVFKsPhOVKhF5LedO68hvxpbreKNwFQOefKHbaQbmGkjP 5Q== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp14.rno.apple.com with ESMTP id 3ewc2ccvn3-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 25 Mar 2022 11:42:05 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.16.20220118 64bit (built Jan 18 2022)) with ESMTPS id <0R9B00G6HDA4CSM0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Fri, 25 Mar 2022 11:42:04 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.16.20220118 64bit (built Jan 18 2022)) id <0R9B00Y00D4G7300@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 25 Mar 2022 11:42:04 -0700 (PDT) X-Va-A: X-Va-T-CD: cc354bcf01ea39de908abab4e73c9ec0 X-Va-E-CD: bde043b851078554223d812060e4060e X-Va-R-CD: b6362e097e9246c95650e17ce55b524d X-Va-CD: 0 X-Va-ID: 131f1f91-fb44-468a-a967-5da2ad144013 X-V-A: X-V-T-CD: cc354bcf01ea39de908abab4e73c9ec0 X-V-E-CD: bde043b851078554223d812060e4060e X-V-R-CD: b6362e097e9246c95650e17ce55b524d X-V-CD: 0 X-V-ID: 4e401b51-f119-4d6b-aa5b-f601f8b15d95 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.850 definitions=2022-03-25_05:2022-03-24,2022-03-25 signatures=0 Received: from smtpclient.apple (unknown [17.235.33.61]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.16.20220118 64bit (built Jan 18 2022)) with ESMTPSA id <0R9B00Q9EDA33V00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 25 Mar 2022 11:42:04 -0700 (PDT) From: "Andrew Fish" Message-id: MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: [edk2-devel] Question about UEFI, AddressSanitizer and MMU mappings Date: Fri, 25 Mar 2022 11:42:03 -0700 In-reply-to: <765AD9BF-54CE-4161-B7D8-BF55A333975F@posteo.de> Cc: pedro.falcato@gmail.com To: devel@edk2.groups.io, mhaeuser@posteo.de References: <765AD9BF-54CE-4161-B7D8-BF55A333975F@posteo.de> X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.850 definitions=2022-03-25_06:2022-03-24,2022-03-25 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_1E456F06-D789-422E-B400-F6521FDE57F0" --Apple-Mail=_1E456F06-D789-422E-B400-F6521FDE57F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>From an UEFI point of view if you own the memory you can do what you want w= ith it. The UEFI Spec does not deal with paging but the PI Spec does have a= bstractions 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 a= ddress mappings?=20 If someone wants to work on ASan (or any of the other sanitizers) I=E2=80= =99m happy to volunteer to consult.=20 [1] https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/C= pu.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=C3=A4user wrot= e: >=20 > Hey Pedro, >=20 > ASan is somewhat listed for =E2=80=9ELLVM Optimizations=E2=80=9C. > A quick and dirty reference for UEFI UBSan can be found here: https://git= hub.com/acidanthera/OpenCorePkg/tree/master/Library/OcGuardLib >=20 > I don=E2=80=99t think you need to strictly adhere to the UEFI spec for de= bug tooling. I cannot check the code now, but I can imagine things like Con= vertPointer() will not be happy about non-identity-mapping OOTB. But the is= sues I can think of should be fairly easy to resolve. >=20 > Best regards, > Marvin >=20 >> On 24. Mar 2022, at 23:32, Pedro Falcato wrote= : >>=20 >> =EF=BB=BF >> Hi! >>=20 >> I've been thinking about adding sanitizer support (UBSan and KASAN), lik= e 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 (i= n the architectures where it requires the MMU being enabled), but nowhere d= o I see anything about the other parts of the address space. >> Of course, UEFI supporting AddressSanitizer would be kind of dependent o= n fancier memory mappings. >>=20 >> Thanks, >> Pedro >=20 --Apple-Mail=_1E456F06-D789-422E-B400-F6521FDE57F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
From an UE= FI point of view if you own the memory you can do what you want with it. Th= e UEFI Spec does not deal with paging but the PI Spec does have abstraction= s for how the CPU operates via the CPU ARCH Protocol [1].

So for example if you want to wr= ite protect the page tables, add guard page, or add a stack guard all that = is OK and exists today [2].
PcdNullPointerDetectionPropertyMask
PcdInitValueInTempStack
PcdHeapGuardPageType
PcdHeapGuardPoolType
PcdHeapGuardPropertyMa= sk
PcdHeapGuar= dPageType
PcdH= eapGuardPropertyMask
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 s= anitizers) I=E2=80=99m 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=C3=A4user <mhaeuser@posteo.de> wrote:
Hey Pedro,

ASan is somewhat listed for =E2= =80=9ELLVM Optimizations=E2=80=9C.
A quick and dirty reference for UEFI UBSan can be found he= re: https://github.com/acidanthera/OpenCorePkg/t= ree/master/Library/OcGuardLib

I don=E2=80=99t think you need to strictly adhere to the UEFI= spec for debug tooling. I cannot check the code now, but I can imagine thi= ngs 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:
=EF=BB=BF
Hi= !

I've been think= ing 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 sto= ps 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 AddressSanit= izer would be kind of dependent on fancier memory mappings.
<= /div>

Thanks,
Pedro

--Apple-Mail=_1E456F06-D789-422E-B400-F6521FDE57F0--