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

["Marvin Häuser" <mhaeuser@posteo.de>]

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

I mean, did you plan to deploy ASan in production? I'm not sure a full 
implementation is performant or compatible with space constraints. Being 
a debug feature, I'm surprised this is a reason for rejection. There is 
toolchain-specific debug stuff live already (e.g. symbols support for 
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 
cooperate? With Virtualisation-Based Security, there is a (hopefully) 
trusted core that can still intervene kernel-mode drivers from acting 
up. I.e., on fault, can one just fail the RT service call and report to 
the OS for it to apply whatever policy it considers appropriate, like 
force-unload the calling driver (if any)? If you do not consider the 
special-case of SMM-guarded security a malicious OS may want to exploit 
(which is a reason why the Amaranth downstream will outright deprecate 
SMM guarding), a malicious OS could just perform any action it may 
provoke the firmware to do itself, so I feel like it's fair if the OS 
was trusted, it cooperated, and it took handling authority.

I guess the only other alternatives are tolerant failure (continue 
business as usual after returning an error) and intolerant failure (shut 
down RT services till reboot).

Of course this should be configurable, so that high-security platforms 
can indeed deadloop or reset the platform.

Best regards,
Marvin

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