From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by mx.groups.io with SMTP id smtpd.web09.8972.1650038438653747223 for ; Fri, 15 Apr 2022 09:00:39 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=HvmprCeF; spf=pass (domain: posteo.de, ip: 185.67.36.66, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 1D09724010B for ; Fri, 15 Apr 2022 18:00:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1650038436; bh=z/KxUhNj7/qVm4+0Tskud9Nu8wGxMMdJMUlRTeIBjx4=; h=Date:Subject:To:Cc:From:From; b=HvmprCeFWhXBc8eLl4xKZ4GzNcqZ6VKSsMz9RWc9Hk7Hyr/yq8S8sLakwe9dwjSUM yF0Zec+HX6ihLORkYmVctbmip1h9ozKew1vj4277CKmmP6O1lS7zm8TnJPluD1ab0j 8WquM2k+lymIotTGp97KXFK1Av0yMrpDCkjCR8tryFqQdhOxGzmRmVhZV5tax/soK9 X5thZNL6An1M/WNMM7FzHREq+g3ffjgTt16zcjIXc6nHHY8dT7qWuKeZvs4UPG56Sg OiEO9LOI/hbkshcHdg/WnK5tEWvOKt9751iYoL2eVcQkhfFFLjaJc/+tfUILHc1AE1 yh+rgfKwNzDrQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Kg1JL6PCGz6tmG; Fri, 15 Apr 2022 18:00:34 +0200 (CEST) Message-ID: <97d9466c-46f3-2f9a-041e-7af95933a124@posteo.de> Date: Fri, 15 Apr 2022 16:00:34 +0000 MIME-Version: 1.0 Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal To: devel@edk2.groups.io, jiewen.yao@intel.com, "discuss@edk2.groups.io" , "Zimmer, Vincent" , Ada Christine , "Desimone, Nathaniel L" , "Kinney, Michael D" Cc: Andrew Fish , Pedro Falcato , "Shi, Steven" References: <865CD9EA-0EB4-4DE9-AFC6-DCB505A067EE@posteo.de> <47C4D916-19E4-48E8-BB81-982F9B70B5DC@apple.com> <56CE4C08-4232-4897-9B0F-6C6443C2C48D@intel.com> <2b70d563-64de-ee20-8b17-a8ed4ac7f29c@posteo.de> From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= In-Reply-To: Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 15.04.22 17:02, Yao, Jiewen wrote: > Exactly. Lacking of doc from different compilers is very painful. > The Asan or UBsan support is just a hack - https://github.com/jyao1/Secur= ityEx/blob/master/StackCheckPkg/Library/StackCheckLib/ASanStub.c > https://github.com/jyao1/SecurityEx/blob/master/StackCheckPkg/Library/Sta= ckCheckLib/UBSanStub.c > > > Another challenge is: What do we do in case of violation? > If you just want a POC or debug purpose, it is easy to use deadloop. I mean, did you plan to deploy ASan in production? I'm not sure a full=20 implementation is performant or compatible with space constraints. Being=20 a debug feature, I'm surprised this is a reason for rejection. There is=20 toolchain-specific debug stuff live already (e.g. symbols support for=20 the RVCT debugger). > If you want to a production, then what do we do in RT driver? deadloop in= OS is not a good idea. As for what to do with RT drivers, I wonder whether Windows can=20 cooperate? With Virtualisation-Based Security, there is a (hopefully)=20 trusted core that can still intervene kernel-mode drivers from acting=20 up. I.e., on fault, can one just fail the RT service call and report to=20 the OS for it to apply whatever policy it considers appropriate, like=20 force-unload the calling driver (if any)? If you do not consider the=20 special-case of SMM-guarded security a malicious OS may want to exploit=20 (which is a reason why the Amaranth downstream will outright deprecate=20 SMM guarding), a malicious OS could just perform any action it may=20 provoke the firmware to do itself, so I feel like it's fair if the OS=20 was trusted, it cooperated, and it took handling authority. I guess the only other alternatives are tolerant failure (continue=20 business as usual after returning an error) and intolerant failure (shut=20 down RT services till reboot). Of course this should be configurable, so that high-security platforms=20 can indeed deadloop or reset the platform. Best regards, Marvin > > > Thank you > Yao Jiewen > >> -----Original Message----- >> From: discuss@edk2.groups.io On Behalf Of Zimme= r, >> Vincent >> Sent: Friday, April 15, 2022 10:54 PM >> To: discuss@edk2.groups.io; mhaeuser@posteo.de; Ada Christine >> ; edk2-devel-groups-io ; >> Desimone, Nathaniel L ; Mike Wolan >> ; Kinney, Michael D >> Cc: Andrew Fish ; Pedro Falcato >> ; Shi, Steven >> Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal >> >> Historically the challenge we had w/ upstreaming some features was if th= e >> compiler intrinsic for which a particular feature was dependent didn't h= ave >> public documentation or wasn't supported by all of the compilers that ED= KII >> supported. For the former, this lack of info would lead to the patches b= eing >> rejected. >> >> Vincent >> >> -----Original Message----- >> From: discuss@edk2.groups.io On Behalf Of Marvi= n >> H=C3=A4user >> Sent: Friday, April 15, 2022 6:40 AM >> To: discuss@edk2.groups.io; Zimmer, Vincent ; = Ada >> Christine ; edk2-devel-groups-io >> ; Desimone, Nathaniel L >> ; Mike Wolan ; >> Kinney, Michael D >> Cc: Andrew Fish ; Pedro Falcato >> ; Shi, Steven >> Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal >> >> Hey Vincent, >> >> In fact I haven't, thanks a lot! Are there any known blockers for these = outside >> development resources? Except for C++, they are things we'd want asap >> downstream. I guess rather than OverflowDetectionPkg, ASan has higher pr= iority >> here. >> >> Best regards, >> Marvin >> >> On 15.04.22 15:31, Zimmer, Vincent wrote: >>> Fyi >>> There is a running list of some edk2 defense-in-depth work at >>> https://github.com/jyao1/SecurityEx/blob/master/Summary.md, too, >>> including ASLR, if you haven't already seen that material >>> >>> -----Original Message----- >>> From: discuss@edk2.groups.io On Behalf Of >>> Marvin H=C3=A4user >>> Sent: Friday, April 15, 2022 5:31 AM >>> To: Ada Christine ; edk2-devel-groups-io >>> ; Desimone, Nathaniel L >>> ; Mike Wolan ; >>> Kinney, Michael D >>> Cc: Andrew Fish ; discuss@edk2.groups.io; Pedro >>> Falcato ; Shi, Steven >>> Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal >>> >>> CC Mike (proposal review as per announcement mail) >>> >>> Hey Ada, >>> >>> I can neither decide on nor even view your proposal (I think that's up = to Nate >> and Mike?), but I had a brief conversation with Vitaly about the Amarant= h >> downstream. There are other potentially technologically related topics V= italy's >> team wants to deploy, including driver sandboxing and ASLR (both will pr= obably >> significantly impact paging). The easiest route for these two is likely = to let go of >> identity mapping. *If* this is feasible and will be accepted upstream, p= relinking >> might become a much simpler matter. For memory protection, all PE/COFF >> image sections must be page-aligned anyway, so depending on how the more >> sophisticated paging would actually work, there may be a lot of wiggle r= oom for >> where to load modules wrt virtual addresses. In *simple and naive* theor= y, they >> could all be assigned a virtual base address at UEFI image construction = (which >> will be free from any physical memory layout constraints due to non-iden= tity >> mapping) and ASLR could just be a slide value that shifts the entire exe= cutable >> UEFI address space around (randomised). With (virtual) addresses known a= t >> build-time, none of that "custom relocation" madness I mentioned before = is >> relevant (gladly). Of course, there needs to be discussion whether fine-= grained >> ASLR would be worth the trouble first. >>> To get more input on the "ecosystem" of security features mentioned (AS= LR, >> sandboxing, prelinking), we will try to discuss it with Microsoft next w= eek. If you >> are interested in a prelinking route, I can let you know. This would unl= ikely be >> quick to deploy, however, and it would need strong support from Intel. I= think >> the overall pool of ideas is clear now and I'll leave it to you and Nate= . Good luck! >>> Best regards, >>> Marvin >>> >>> On 15.04.22 14:09, Ada Christine wrote: >>>> Hi Everybody >>>> >>>> I've read all the discussion here and condensed my plan into a short >>>> project proposal. It's a little short and light on detail at the >>>> moment because I'm pressed for time for other matters today, but I >>>> wanted to get something in before EOD today as requested. Anybody >>>> else's input or a change in the overall strategy to allow for code >>>> sharing between DXE modules, whether it be prelinking or some kind of >>>> function pointer table is absolutely welcome and I'm not attached to >>>> any particular way of solving the code repetition problem. You can >>>> find my proposal here >>>> https://summerofcode.withgoogle.com/proposals/details/whGX9tXL >>>> >>>> Looking forward to your commentary! >>>> >>>> Thanks! >>>> - Ada Christine >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> >> >> > > >=20 > >