Exactly. Lacking of doc from different compilers is very painful. The Asan or UBsan support is just a hack - https://github.com/jyao1/SecurityEx/blob/master/StackCheckPkg/Library/StackCheckLib/ASanStub.c https://github.com/jyao1/SecurityEx/blob/master/StackCheckPkg/Library/StackCheckLib/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. If you want to a production, then what do we do in RT driver? deadloop in OS is not a good idea. Thank you Yao Jiewen > -----Original Message----- > From: disc...@edk2.groups.io <disc...@edk2.groups.io> On Behalf Of Zimmer, > Vincent > Sent: Friday, April 15, 2022 10:54 PM > To: disc...@edk2.groups.io; mhaeu...@posteo.de; Ada Christine > <adachristin...@gmail.com>; edk2-devel-groups-io <devel@edk2.groups.io>; > Desimone, Nathaniel L <nathaniel.l.desim...@intel.com>; Mike Wolan > <mwo...@caseking.de>; Kinney, Michael D <michael.d.kin...@intel.com> > Cc: Andrew Fish <af...@apple.com>; Pedro Falcato > <pedro.falc...@gmail.com>; Shi, Steven <steven....@intel.com> > Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal > > Historically the challenge we had w/ upstreaming some features was if the > compiler intrinsic for which a particular feature was dependent didn't have > public documentation or wasn't supported by all of the compilers that EDKII > supported. For the former, this lack of info would lead to the patches being > rejected. > > Vincent > > -----Original Message----- > From: disc...@edk2.groups.io <disc...@edk2.groups.io> On Behalf Of Marvin > Häuser > Sent: Friday, April 15, 2022 6:40 AM > To: disc...@edk2.groups.io; Zimmer, Vincent <vincent.zim...@intel.com>; Ada > Christine <adachristin...@gmail.com>; edk2-devel-groups-io > <devel@edk2.groups.io>; Desimone, Nathaniel L > <nathaniel.l.desim...@intel.com>; Mike Wolan <mwo...@caseking.de>; > Kinney, Michael D <michael.d.kin...@intel.com> > Cc: Andrew Fish <af...@apple.com>; Pedro Falcato > <pedro.falc...@gmail.com>; Shi, Steven <steven....@intel.com> > 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 priority > 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: disc...@edk2.groups.io <disc...@edk2.groups.io> On Behalf Of > > Marvin Häuser > > Sent: Friday, April 15, 2022 5:31 AM > > To: Ada Christine <adachristin...@gmail.com>; edk2-devel-groups-io > > <devel@edk2.groups.io>; Desimone, Nathaniel L > > <nathaniel.l.desim...@intel.com>; Mike Wolan <mwo...@caseking.de>; > > Kinney, Michael D <michael.d.kin...@intel.com> > > Cc: Andrew Fish <af...@apple.com>; disc...@edk2.groups.io; Pedro > > Falcato <pedro.falc...@gmail.com>; Shi, Steven <steven....@intel.com> > > 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 Amaranth > downstream. There are other potentially technologically related topics > Vitaly's > team wants to deploy, including driver sandboxing and ASLR (both will probably > 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, > prelinking > 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 room > for > where to load modules wrt virtual addresses. In *simple and naive* theory, > 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-identity > mapping) and ASLR could just be a slide value that shifts the entire > executable > UEFI address space around (randomised). With (virtual) addresses known at > 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 (ASLR, > sandboxing, prelinking), we will try to discuss it with Microsoft next week. > If you > are interested in a prelinking route, I can let you know. This would unlikely > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88944): https://edk2.groups.io/g/devel/message/88944 Mute This Topic: https://groups.io/mt/90435699/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
