Re: [edk2-devel] [edk2-discuss] GSoC Proposal

["Yao, Jiewen" <jiewen.yao@intel.com>]

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: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Zimmer,
> Vincent
> Sent: Friday, April 15, 2022 10:54 PM
> To: discuss@edk2.groups.io; mhaeuser@posteo.de; Ada Christine
> <adachristine18@gmail.com>; edk2-devel-groups-io <devel@edk2.groups.io>;
> Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Mike Wolan
> <mwolan@caseking.de>; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Andrew Fish <afish@apple.com>; Pedro Falcato
> <pedro.falcato@gmail.com>; Shi, Steven <steven.shi@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: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Marvin
> Häuser
> Sent: Friday, April 15, 2022 6:40 AM
> To: discuss@edk2.groups.io; Zimmer, Vincent <vincent.zimmer@intel.com>; Ada
> Christine <adachristine18@gmail.com>; edk2-devel-groups-io
> <devel@edk2.groups.io>; Desimone, Nathaniel L
> <nathaniel.l.desimone@intel.com>; Mike Wolan <mwolan@caseking.de>;
> Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Andrew Fish <afish@apple.com>; Pedro Falcato
> <pedro.falcato@gmail.com>; Shi, Steven <steven.shi@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: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
> > Marvin Häuser
> > Sent: Friday, April 15, 2022 5:31 AM
> > To: Ada Christine <adachristine18@gmail.com>; edk2-devel-groups-io
> > <devel@edk2.groups.io>; Desimone, Nathaniel L
> > <nathaniel.l.desimone@intel.com>; Mike Wolan <mwolan@caseking.de>;
> > Kinney, Michael D <michael.d.kinney@intel.com>
> > Cc: Andrew Fish <afish@apple.com>; discuss@edk2.groups.io; Pedro
> > Falcato <pedro.falcato@gmail.com>; Shi, Steven <steven.shi@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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 
> 
> 
> 
>