-----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
