From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by mx.groups.io with SMTP id smtpd.web10.239.1648241264805932188 for ; Fri, 25 Mar 2022 13:47:45 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ZGUy9ZRM; spf=pass (domain: gmail.com, ip: 209.85.217.50, mailfrom: pedro.falcato@gmail.com) Received: by mail-vs1-f50.google.com with SMTP id s18so9605470vsr.1 for ; Fri, 25 Mar 2022 13:47:44 -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=wH4oLU/YeIo31H4Pb/yXEdSJQ8Duc2dwYBQvMjCd1PI=; b=ZGUy9ZRMclp4rkl0AMjQxb699Us11GWYMMR1lNowAmEYMH5UD32nnBUi3lrkfVrEka dfhLK79Knq7dOyo+oSG3e/xD0UiqUxah5f25JS/n0iH0E7rmnSJN3EvhDxkBizfSrGCX 3WGxAi16iMB6vLCsdnMEQ17xmCnkbNWUmHwG4kqUjG39O2ljdJyW/F2A+h3igXpvZPVi yinZu+4guUDEFG0KrVusVNSjoRb73P12VCL+fUILJJIoGhpNsMje9d4oGbaspHGydVlD ImxgIOyFKgZuaWm6QqWeKu+gw/Or8KD7GNbtmKw69ilf8BopI5TJQInRtsMTbSNrn6Rf FcZg== 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=wH4oLU/YeIo31H4Pb/yXEdSJQ8Duc2dwYBQvMjCd1PI=; b=V08frG9CYTugBY0Gsbu5W6W7SKVI2UhhOMHsWk2JGAJGxCXmR3LPqee1+hK1RpWct+ ubGA5cbIlcU4Ac0S9zNSue2jyuYVlslawpOVxXqTy4bGvuD4aP5M0/He7b47f/HerS3O 0PYI0EVpc+OLbiaoB0kfXSft+l/R8DAlZ+O1EgIxd+MY6n9i9UMQV553V9gD/xp3EgPK uvIys1J+l8kuNznoPzUDXObq04djmC4uSyDQJLiprANIasDo7S2NskYRYQvviXmFxPBx gxAtJ3rqYMcBH1tV7wP06+o4fXH+3J6pVbPNIW7QG9No9dPcvBrWBItUvbcF/u5s5Mjk AJPA== X-Gm-Message-State: AOAM532Le8Pog1hI1KBzUSUjvPVFGePnSXEL4gByeIq3ceWZRhxD94y/ kSCrs2FPCenOjhxkSnDNn1bt8Ttv3R3wiW9UL+CIg70XDnRW1g== X-Google-Smtp-Source: ABdhPJzSZpEjPue5PwgnaAJH3QgqUdLUJvM+CjRnTq08OErRIM52/7vtnUyqu/gTAi1FQ6boxNhLdoma0Faz1TThqhE= X-Received: by 2002:a67:e3bb:0:b0:320:c5f7:9647 with SMTP id j27-20020a67e3bb000000b00320c5f79647mr6100705vsm.7.1648241263776; Fri, 25 Mar 2022 13:47:43 -0700 (PDT) MIME-Version: 1.0 References: <765AD9BF-54CE-4161-B7D8-BF55A333975F@posteo.de> In-Reply-To: From: "Pedro Falcato" Date: Fri, 25 Mar 2022 20:47:32 +0000 Message-ID: Subject: Re: [edk2-devel] Question about UEFI, AddressSanitizer and MMU mappings To: edk2-devel-groups-io , Andrew Fish Cc: =?UTF-8?Q?Marvin_H=C3=A4user?= Content-Type: multipart/alternative; boundary="0000000000000816e305db11135b" --0000000000000816e305db11135b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 > > >=20 > > --=20 Pedro Falcato --0000000000000816e305db11135b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Andrew, Marvin,

Thanks for the quick re= sponses.

I'll give you a rundown of asan/kasan= : You create a big (16TB in PML5-less x86) virtual mapping for ASAN, each b= yte in the shadow map represents 8 bytes of address space, and you poison/u= npoison 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 a= s 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; usua= lly, this means that you set up some page tables pointing to a zero page an= d 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 y= ou can RW to them).

Note that going a different ro= ute (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 gene= rate for you (which do these same memory accesses, but inlined instead of d= oing e.g call __asan_load_8).

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

Since adding Addr= essSanitizer support is pretty involved (build system + actual ASAN code + = MMU support code for each arch), I feel like it would be a good large proje= ct 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 kno= w if that's too much for a GSoC student. Would love some feedback on th= is.

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 i= nterested in this project.

Best regards,
Pedro=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 w= ant with it. The UEFI Spec does not deal with paging but the PI Spec does h= ave 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 tod= ay [2].
Pcd= NullPointerDetectionPropertyMask
PcdInitValueInTempStack
PcdHeapGuardPageType
PcdHeapGu= ardPoolType
PcdHeapGuardPropertyMask
PcdHeapGuardPageType
PcdHeapGuardPropertyMask
PcdCpuSt= ackGuard

Does Asan just need to force page = faults? Or does it want to make virtual address mappings?=C2=A0
<= br>
If someone wants to work on ASan (or any of the other sanitiz= ers) I=E2=80=99m happy to volunteer to consult.=C2=A0

<= div>[1]=C2=A0https://github.com/tianoco= re/edk2/blob/master/MdePkg/Include/Protocol/Cpu.h#L221

T= hanks,

Andrew Fish

On Mar 25, 2022, at 2:07 AM, Marvin H=C3=A4user <mhaeuser@posteo.de> wro= te:

Hey Pedro,

<= div dir=3D"ltr" style=3D"font-family:Helvetica;font-size:12px;font-style:no= rmal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text= -align:start;text-indent:0px;text-transform:none;white-space:normal;word-sp= acing:0px;text-decoration:none">ASan is somewhat listed for =E2=80=9ELLVM O= ptimizations=E2=80=9C.
A quick and di= rty reference for UEFI UBSan can be found here:=C2=A0https://github.com/acidanthera/OpenCorePkg/tree/master/Library/OcGua= rdLib

I don=E2=80=99t think you need to strictly adhere to the UE= FI spec for debug tooling. I cannot check the code now, but I can imagine t= hings like ConvertPointer() will not be happy about non-identity-mapping OO= TB. But the issues I can think of should be fairly easy to resolve.

B= est regards,
Marvin

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

=EF=BB=BF
Hi!

I've been thinking about add= ing 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 somet= hing.
Is there anything in the UEFI spec that stops us from doing= non-identity memory mappings? I know it specifies the need for the identit= y 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 depen= dent on fancier memory mappings.

Thanks,
=
Pedro
<= /blockquote>

=20



--
Pedro Falcato
--0000000000000816e305db11135b--