From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by mx.groups.io with SMTP id smtpd.web11.13240.1648485060331316884 for ; Mon, 28 Mar 2022 09:31:00 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=kQ2bRVEN; spf=pass (domain: gmail.com, ip: 209.85.217.48, mailfrom: pedro.falcato@gmail.com) Received: by mail-vs1-f48.google.com with SMTP id m184so16269667vsm.12 for ; Mon, 28 Mar 2022 09:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ckvpEsXmB9lgaFDke31LYukN/py/nCcAc9oB7eJgK5A=; b=kQ2bRVENsBsz0W4fP89d+7zpmvwriBH7gR4wvWNtKVJEwzAITLZB51YX5c1CkqTiDH i7C79yQ/nMU3ojtGTlI1wKTDQzbzADXEsY7qDPulyv85Yx5+7wGgf9EgxRBc9LdGM5Ox PCY3KVcjuVqh5UcadKfwYz0C3m0N7Y3b5JtbgrowZBqQn1radMo+UO/EBYM8UzT0hFQe q7Y2hhyYOfrCE8cjZn23BzgIaoFnStsNHv5VTX90U2/+ku9cshb274OqfngaIKvSif2r T4IiuiguZ2E2CsNYBHmjgp0NRRvQ1dqGNoxX+j2xFhwG9QGuwcEPLY3kOq4iejjZWiXR LaNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ckvpEsXmB9lgaFDke31LYukN/py/nCcAc9oB7eJgK5A=; b=sVqjNb39wtnN/ZXArkupZJ93G90m6TYxvdaFqOe03ivmPB20OQUOQW8c/19GaXotlw k7mtnJDgYsSBn3kZzO+DU/3+TQGXQg1fUVzEAT5VHqp6bK1gtWIk5XITmCHTLq7FX82s RUMGy/PD8mSOOKbEgwwLk0VlNnApo/0PeZYOgP/Pz1AnldFnKHMODi26nqcBicknWqPt 51COWK3S8YFpN1HM0Vdt7aLqLXa/orW3uBKNRvxif6huWt9Vg9E9LA2h+5oYMBL3wECL /LQPYOK3cWGbsChqCVjmWMTdeLWfGie5FVLd7zsT9mqQjGtcU6wb/9LGB8FaOur/0wGx KZeQ== X-Gm-Message-State: AOAM531BlWXRJ30kZCeDoFrPW7HOohiOQZjeW7b9hJFq9eGFlKP6AW07 Wo36XZZWUMTzVP1+XgcstbImphrdOeqeaV8A2SbrcTO5O35e0zVe X-Google-Smtp-Source: ABdhPJyroquMCTRG9Ey0tyL6qhJQkhqVztLrNcANsqIdUaUCVRUQ0ckgPd8zDTxQMf3zu1WmxwN+JBqjylvlXmmcf5s= X-Received: by 2002:a05:6102:32d2:b0:325:7415:7190 with SMTP id o18-20020a05610232d200b0032574157190mr6955389vss.6.1648485059142; Mon, 28 Mar 2022 09:30:59 -0700 (PDT) MIME-Version: 1.0 References: <765AD9BF-54CE-4161-B7D8-BF55A333975F@posteo.de> In-Reply-To: From: "Pedro Falcato" Date: Mon, 28 Mar 2022 17:30:47 +0100 Message-ID: Subject: Re: [edk2-devel] Question about UEFI, AddressSanitizer and MMU mappings To: edk2-devel-groups-io , steven.shi@intel.com Cc: Andrew Fish , "vit9696@protonmail.com" , =?UTF-8?Q?Marvin_H=C3=A4user?= , "Kinney, Michael D" , "Zimmer, Vincent" , "Schulz, Steffen" , "Tarral, Mathieu" , "Morgan, Benoit" , "Xu, Min" , "Liu, Wei" Content-Type: multipart/alternative; boundary="0000000000005e28f005db49d6fb" --0000000000005e28f005db49d6fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Steven! Good to know you already have something. I removed your LLVM Optimizations suggestion that was about MPX, as Intel MPX is pretty dead (Intel is dropping it, compilers don't support it) as far as I know, and added a new suggestion for UBSan, ASAN, and possibly MSAN ( https://github.com/tianocore/tianocore.github.io/wiki/Tasks#LLVM_Sanitizer_= support), mentioning your branch; note that I still left you in the "suggested by:". I briefly looked at your code, and it seems that you had a different idea for shadow memory allocation. My idea (custom shadow mappings) uses up less memory and is probably way faster to boot, although I don't think it's possible to use it in runtime services/SMM. Is it even important to instrument these with ASAN? I was thinking that most of the need was in PEI/DXE, not those. Best regards, Pedro On Mon, Mar 28, 2022 at 12:32 PM Steven Shi wrote: > We enabled Asan and UBsan on edk2 DXE in 2017 after we introduced the > CLANG38 build toolchain in edk2. It was quite useful to find dozens of co= de > bugs. It is not difficult as it sounds, but we never finished all the > scope, e.g., PEI, SMM. There are many limitations in current > implementation, e.g., not cover page memory service. I=E2=80=99m glad if = some > people can continue to enhance it and finish it. > > > > The edk2 sanitizer branch: > > https://github.com/shijunjing/edk2/tree/sanitizer2 > > Edk2 sanitizer slides: > > https://github.com/shijunjing/edk2/blob/sanitizer2/Edk2ASan.pptx > > Usage readme: > > https://github.com/shijunjing/edk2/blob/sanitizer2/readme_sanitizer.txt > > > > - OvmfPkgIa32X64 build with sanitizers on edk2 and run: > > jshi19@ub2-uefi-b01:~/wksp_efi/edk2-fork4$ git remote -v > > origin https://github.com/shijunjing/edk2.git (fetch) > > origin https://github.com/shijunjing/edk2.git (push) > > jshi19@ub2-uefi-b01:~/wksp_efi/edk2-fork4$ git status > > On branch sanitizer2 > > jshi19@ub2-uefi-b01:~/wksp_efi/edk2-fork4$ export > CLANGSAN40_BIN=3D~/llvm/clang+llvm-11.0.0-x86_64-linux-gnu-ubuntu-20.04/b= in/export > CLANGSAN40_BIN=3D~/llvm/clang+llvm-11.0.0-x86_64-linux-gnu-ubuntu-20.04/b= in/ > > jshi19@ub2-uefi-b01:~/wksp_efi/edk2-fork4$ rm Conf/tools_def.txt > > jshi19@ub2-uefi-b01:~/wksp_efi/edk2-fork4$ rm Conf/build_rule.txt > > jshi19@ub2-uefi-b01:~/wksp_efi/edk2-fork4$ rm Conf/target.txt > > jshi19@ub2-uefi-b01:~/wksp_efi/edk2-fork4$ source edksetup.sh > > jshi19@ub2-uefi-b01:~/wksp_efi/edk2-fork4$ make -C BaseTools/ > > jshi19@ub2-uefi-b01:~/wksp_efi/edk2-fork4$ build -p > OvmfPkg/OvmfPkgIa32X64.dsc -t CLANGSAN40 -a IA32 -a X64 -b NOOPT -n 5 > -DDEBUG_ON_SERIAL_PORT > > jshi19@ub2-uefi-b01:~/wksp_efi/edk2-fork4$ qemu-system-x86_64 -m 5120 > -smp 1 -bios > ~/wksp_efi/edk2-fork4/Build/Ovmf3264/NOOPT_CLANGSAN40/FV/OVMF.fd -global > e1000.romfile=3D"" -machine q35 -serial mon:stdio -display none --net no= ne > > > > - To see the enabling code: > > jshi19@ub2-uefi-b01:~/wksp_efi/edk2-fork4$ git diff 4adc364c --name-only > > > > - Asan Shadow Memory setup: > > > https://github.com/shijunjing/edk2/blob/sanitizer2/OvmfPkg/PlatformPei/Me= mDetect.c#L1133 > > > > - The compiler instrumentation routines for AddressSanitizer(ASan) > > > https://github.com/shijunjing/edk2/blob/sanitizer2/MdeModulePkg/Library/A= sanLib/Asan.c > > > > This Asan branch was synced to latest edk2 early this month by some > people=E2=80=99s fuzz test requirement. But I didn=E2=80=99t 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 *Pedro > Falcato > *Sent:* Saturday, March 26, 2022 4:48 AM > *To:* edk2-devel-groups-io ; Andrew Fish < > afish@apple.com> > *Cc:* Marvin H=C3=A4user > *Subject:* Re: [edk2-devel] Question about UEFI, AddressSanitizer and MMU > mappings > > > > Andrew, Marvin, > > > > Thanks for the quick responses. > > > > I'll give you a rundown of asan/kasan: You create a big (16TB in PML5-les= s > 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 yo= u > have is a large contiguous virtual mapping, you need to either take a pag= e > 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 th= at > 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 th= e > 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 in= to > 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 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 hav= e > 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=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.d= ec#L979 > > > > Thanks, > > > > Andrew Fish > > > > On Mar 25, 2022, at 2:07 AM, Marvin H=C3=A4user wrot= e: > > > > 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 here: > https://github.com/acidanthera/OpenCorePkg/tree/master/Library/OcGuardLib > > > > 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 > ConvertPointer() will not be happy about non-identity-mapping OOTB. But t= he > issues I can think of should be fairly easy to resolve. > > > > Best regards, > > Marvin > > > > On 24. Mar 2022, at 23:32, Pedro Falcato wrote: > > =EF=BB=BF > > 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 d= o > 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 > > > > > > > -- > > Pedro Falcato > >=20 > > --=20 Pedro Falcato --0000000000005e28f005db49d6fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Steven!

Good to know you = already have something. I removed your LLVM Optimizations suggestion that w= as about MPX, as Intel MPX is pretty dead (Intel is dropping it, compilers = don't support it) as far as I know, and added
a new suggestio= n for UBSan, ASAN, and possibly MSAN (https://github.co= m/tianocore/tianocore.github.io/wiki/Tasks#LLVM_Sanitizer_support), men= tioning your branch; note that I still left you in the "suggested by:&= quot;.

I briefly looked at your code, and it seems= that you had a different idea for shadow memory allocation. My idea (custo= m shadow mappings) uses up less memory and is probably way faster to boot, = although I don't think it's possible to use it in runtime
services/SMM. Is it even important to instrument these with ASAN? I was th= inking that most of the need was in PEI/DXE, not those.

<= /div>
Best regards,
Pedro

On Mon, Mar 28, 2022 at 12= :32 PM Steven Shi <steven.shi@in= tel.com> wrote:

We enabled Asan and UBsan on edk2 DXE in 2017 after = we introduced the CLANG38 build toolchain in edk2. It was quite useful to f= ind dozens of code bugs. It is not difficult as it sounds, but we never fin= ished all the scope, e.g., PEI, SMM. There are many limitations in current implementation, e.g., not cover page= memory service. I=E2=80=99m glad if some people can continue to enhance it= and finish it.

=C2=A0

The edk2 sanitizer branch:

https://github.com/shijunjing/edk2/tree/saniti= zer2

Edk2 sanitizer slides:

https://github.com/shijunjing/ed= k2/blob/sanitizer2/Edk2ASan.pptx

Usage readme:

https://github.com/shijun= jing/edk2/blob/sanitizer2/readme_sanitizer.txt

=C2=A0

  • OvmfPkgIa32X64 build= with sanitizers on edk2 and run:

jshi19@ub2-uefi-b01:~= /wksp_efi/edk2-fork4$ git remote -v

origin=C2=A0 https://github.com/shijunjing/edk2.git (fetch)

origin=C2=A0 https://github.com/shijunjing/edk2.git (push)

jshi19@ub2-uefi-b01:~= /wksp_efi/edk2-fork4$ git status

On branch sanitizer2=

jshi19@ub2-uefi-b01:~= /wksp_efi/edk2-fork4$ export CLANGSAN40_BIN=3D~/llvm/clang+llvm-11.0.0-x86_= 64-linux-gnu-ubuntu-20.04/bin/export CLANGSAN40_BIN=3D~/llvm/clang+llvm-11.= 0.0-x86_64-linux-gnu-ubuntu-20.04/bin/

jshi19@ub2-uefi-b01:~= /wksp_efi/edk2-fork4$ rm Conf/tools_def.txt

jshi19@ub2-uefi-b01:~= /wksp_efi/edk2-fork4$ rm Conf/build_rule.txt

jshi19@ub2-uefi-b01:~= /wksp_efi/edk2-fork4$ rm Conf/target.txt

jshi19@ub2-uefi-b01:~= /wksp_efi/edk2-fork4$ source edksetup.sh

jshi19@ub2-uefi-b01:~= /wksp_efi/edk2-fork4$ make -C BaseTools/

jshi19@ub2-uefi-b01:~= /wksp_efi/edk2-fork4$ build -p OvmfPkg/OvmfPkgIa32X64.dsc -t CLANGSAN40 -a = IA32 -a X64 -b NOOPT -n 5 -DDEBUG_ON_SERIAL_PORT

jshi19@ub2-uefi-b01:~= /wksp_efi/edk2-fork4$ qemu-system-x86_64 -m 5120 -smp 1 -bios ~/wksp_efi/ed= k2-fork4/Build/Ovmf3264/NOOPT_CLANGSAN40/FV/OVMF.fd -global e1000.romfile= =3D""=C2=A0 -machine q35 -serial mon:stdio -display none --net no= ne

=C2=A0<= /p>

  • To see the enabling = code:

jshi19@ub2-uefi-b01:~/wksp_efi/edk2-fork4$ git diff = 4adc364c --name-only

=C2=A0

  • Asan Shadow Memory s= etup:

https://= github.com/shijunjing/edk2/blob/sanitizer2/OvmfPkg/PlatformPei/MemDetect.c#= L1133

=C2=A0

  • The compiler instrum= entation routines for AddressSanitizer(ASan)

https://gi= thub.com/shijunjing/edk2/blob/sanitizer2/MdeModulePkg/Library/AsanLib/Asan.= c

=C2=A0

This Asan branch was synced to latest edk2 early thi= s month by some people=E2=80=99s fuzz test requirement. But I didn=E2=80=99= t really test it. I would like to help if there is something wrong in it. L= et me know.

=C2=A0

=C2=A0

Thanks

Steven Shi

=C2=A0

=C2=A0

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pedro Falcato
Sent: Saturday, March 26, 2022 4:48 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Andrew Fish <afish@apple.com>
Cc: Marvin H=C3=A4user <mhaeuser@posteo.de>
Subject: Re: [edk2-devel] Question about UEFI, AddressSanitizer and = MMU mappings

=C2=A0

Andrew, Marvin,

=C2=A0

Thanks for the quick responses.

=C2=A0

I'll give you a rundown of asan/kasan: You creat= e 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 mem= ory as you go and allocate chunks of the address space (usually through malloc, but in our case, AllocatePool()/All= ocatePages(), I imagine). Since the only thing you have is a large contiguo= us virtual mapping, you need to either take a page fault and create mapping= s on the address space as you go along (very possible in user-space, usually not possible in kernel space a= nd I assume UEFI), or you need to do fun stuff w/ page tables; usually, thi= s 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 a= llocate shadow pages for those (so you can RW to them).

=C2=A0

Note that going a different route (with some data st= ructure 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).

=C2=A0

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

=C2=A0

Since adding AddressSanitizer support is pretty invo= lved (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 tempt= ed 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.

=C2=A0

Note: I would like to work on this, but since I'= ll be a mentor this year I prefer to first=C2=A0see if a student is interes= ted in this project.

=C2=A0

Best regards,

Pedro=C2=A0

=C2=A0

On Fri, Mar 25, 2022 at 6:42 PM Andrew Fish via groups.io <afish=3Dapple.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 ARC= H Protocol [1].

=C2=A0

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 tod= ay [2].

PcdNullPointerDetectionProperty= Mask

PcdInitValueInTempStack<= u>

PcdHeapGuardPageType<= /u>

PcdHeapGuardPoolType<= /u>

PcdHeapGuardPropertyMask=

PcdHeapGuardPageType<= /u>

PcdHeapGuardPropertyMask=

PcdCpuStackGuard<= u>

=C2=A0

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

=C2=A0

If someone wants to work on ASan (or any of the othe= r sanitizers) I=E2=80=99m happy to volunteer to consult.=C2=A0

=C2=A0

=C2=A0

Thanks,

=C2=A0

Andrew Fish



=C2=A0

Hey Pedro,

=C2=A0

ASan is somewhat listed for =E2=80=9ELLVM Optimizati= ons=E2=80=9C.

=C2=A0

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 im= agine things like ConvertPointer() will not be happy about non-identity-mapping OOTB. But the issues I can think of should be f= airly easy to resolve.

=C2=A0

Best regards,

Marvin



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

=EF=BB=BF

Hi!

=C2=A0

I've been thinking about adding sanitizer suppor= t (UBSan and KASAN), like coreboot already has, to the wiki's Tasks for= the upcoming GSoC, but I'm a bit confused by something.<= /span>

Is there anything in the UEFI spec that stops us fro= m 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 th= e other parts of the address space.

Of course, UEFI supporting AddressSanitizer would be= kind of dependent on fancier memory mappings.

=C2=A0

Thanks,

Pedro

=C2=A0


=C2=A0

--

Pedro Falcato

=20



--
Pedro Falcato
--0000000000005e28f005db49d6fb--