[edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings

[Taylor Beebe]

I am going to extend the opportunity for feedback to the end of Tuesday. 
I would very much like more community input on this proposal.

On 7/30/2021 11:42 AM, Sean Brogan wrote:
> Jiewen,
> 
> **Slight rant**
> 
> I agree with libraries as an effective abstraction method.  But I think 
> there needs to be a broad discussion about the order of preference for 
> methods of abstraction.  Today the edk2 code base is a mix and often 
> there are numerous methods abstracting the same thing which leads to 
> confusion, misconfiguration, and error.
> 
> In the UEFI specification we have PPIs/Protocols/Events for functional 
> abstraction.  We have variables, guided config tables, and HII for data 
> abstraction.
> 
> In the PI specification we add HOBs and PCDs for data abstractions.
> 
> Finally, in EDKII we add the library class concept and leverage it 
> heavily for arch, phase, and platform/behavioral abstractions.
> 
> Without clear guidance for how and when to use the above it is hard to 
> keep code being developed by the larger community consistent.
> 
> **End**
> 
> I was leaning towards something closer to
> 
>  >> Option 1: 
> https://github.com/TaylorBeebe/edk2/tree/memory_protection_lib_2
> 
> the HOB method and internally as we develop more code we are preferring 
> HOB and data abstractions more than functional abstraction.  Data 
> abstractions can be used to control functional differences as well if 
> needed.  Data abstractions allow for easier validation and support 
> diverse code environments.  For example standalone MM and 
> payloadpkg/payload concepts.  Finally, data abstractions break the need 
> for a monolithic code base.   But as you can see in option 1 it actually 
> uses a library class abstraction as well because no one wants to write 
> the same code over and over again to get the HOB.  The contract of the 
> library is just data but it still requires library mappings.  Maybe 
> these types of libraries need to be treated differently.
> 
> Anyway it would be great to hear from other members of the community 
> around not just the memory protections RFC (this RFC) but around 
> preferences for abstraction techniques (pro/con).  If an actual 
> discussion starts it could move to design meeting.
> 
> Thanks
> Sean
> 
> 
> 
> 
> 
> 
> 
> On 7/29/2021 7:34 PM, Yao, Jiewen wrote:
>> Thanks. Code talks better.
>>
>> I prefer option 2, which is a generic way for abstraction.
>>
>> And you may enable option 1 under the cover of option 2, just create a 
>> lib instance to get config from Hob.
>>
>> Thank you
>> Yao Jiewen
>>
>>> -----Original Message-----
>>> From: Taylor Beebe <t at taylorbeebe.com>
>>> Sent: Friday, July 30, 2021 10:07 AM
>>> To: Yao, Jiewen <jiewen.yao at intel.com>; Wang, Jian J 
>>> <jian.j.wang at intel.com>;
>>> devel at edk2.groups.io
>>> Cc: spbrogan at outlook.com; Dong, Eric <eric.dong at intel.com>; Ni, Ray
>>> <ray.ni at intel.com>; Kumar, Rahul1 <rahul1.kumar at intel.com>;
>>> mikuback at linux.microsoft.com; Wu, Hao A <hao.a.wu at intel.com>; Bi, Dandan
>>> <dandan.bi at intel.com>; gaoliming at byosoft.com.cn; Dong, Guo
>>> <guo.dong at intel.com>; Ma, Maurice <maurice.ma at intel.com>; You, Benjamin
>>> <benjamin.you at intel.com>
>>> Subject: Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings
>>>
>>> Of course - here are a couple of rough drafts:
>>>
>>> Option 1: 
>>> https://github.com/TaylorBeebe/edk2/tree/memory_protection_lib_2
>>> Option 2: https://github.com/TaylorBeebe/edk2/tree/memory_protection_lib
>>>
>>> On 7/29/2021 6:57 PM, Yao, Jiewen wrote:
>>>> Hi
>>>> Sorry, I am not able to follow the discussion.
>>>>
>>>> Is there any sample or POC code to show the concept?
>>>>
>>>>> -----Original Message-----
>>>>> From: Taylor Beebe <t at taylorbeebe.com>
>>>>> Sent: Friday, July 30, 2021 9:55 AM
>>>>> To: Wang, Jian J <jian.j.wang at intel.com>; devel at edk2.groups.io
>>>>> Cc: spbrogan at outlook.com; Dong, Eric <eric.dong at intel.com>; Ni, Ray
>>>>> <ray.ni at intel.com>; Kumar, Rahul1 <rahul1.kumar at intel.com>;
>>>>> mikuback at linux.microsoft.com; Wu, Hao A <hao.a.wu at intel.com>; Bi,
>>> Dandan
>>>>> <dandan.bi at intel.com>; gaoliming at byosoft.com.cn; Dong, Guo
>>>>> <guo.dong at intel.com>; Ma, Maurice <maurice.ma at intel.com>; You,
>>> Benjamin
>>>>> <benjamin.you at intel.com>; Yao, Jiewen <jiewen.yao at intel.com>
>>>>> Subject: Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard 
>>>>> Settings
>>>>>
>>>>> Thanks for your feedback, Jian.
>>>>>
>>>>> In option 2, a most basic implementation would returning the current
>>>>> FixedAtBuild PCDs assuming they are kept. If they aren't, the library
>>>>> implementer could simply hard-code the return value for each memory
>>>>> protection setting.
>>>>>
>>>>> In option 1, the HOB would be published in pre-mem and I'm not an 
>>>>> expert
>>>>> on exploiting the pre-mem environment. Jiewen may have more to say on
>>> this.
>>>>>
>>>>> -Taylor
>>>>>
>>>>> On 7/28/2021 7:18 PM, Wang, Jian J wrote:
>>>>>> Thanks for the RFC. I'm not object to this idea. The only concern 
>>>>>> from me
>>>>>> is the potential security holes introduced by the changes. 
>>>>>> According to your
>>>>>> description, it allows 3rd party software to violate memory 
>>>>>> protection
>>> policy.
>>>>>> I'd like to see more explanations on how to avoid it to be exploited.
>>>>>>
>>>>>> +Jiewen, what's current process to evaluate the security threat?
>>>>>>
>>>>>> Regards,
>>>>>> Jian
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Taylor Beebe <t at taylorbeebe.com>
>>>>>>> Sent: Friday, July 23, 2021 8:33 AM
>>>>>>> To: devel at edk2.groups.io
>>>>>>> Cc: spbrogan at outlook.com; Dong, Eric <eric.dong at intel.com>; Ni, Ray
>>>>>>> <ray.ni at intel.com>; Kumar, Rahul1 <Rahul1.Kumar at intel.com>;
>>>>>>> mikuback at linux.microsoft.com; Wang, Jian J <jian.j.wang at intel.com>;
>>> Wu,
>>>>>>> Hao A <hao.a.wu at intel.com>; Bi, Dandan <dandan.bi at intel.com>;
>>>>>>> gaoliming at byosoft.com.cn; Dong, Guo <guo.dong at intel.com>; Ma,
>>>>> Maurice
>>>>>>> <maurice.ma at intel.com>; You, Benjamin <benjamin.you at intel.com>
>>>>>>> Subject: [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings
>>>>>>>
>>>>>>> Current memory protection settings rely on FixedAtBuild PCD values
>>>>>>> (minus PcdSetNxForStack). Because of this, the memory protection
>>>>>>> configuration interface is fixed in nature. Cases arise in which 
>>>>>>> memory
>>>>>>> protections might need to be adjusted between boots (if platform 
>>>>>>> design
>>>>>>> allows) to avoid disabling a system. For example, platforms might 
>>>>>>> choose
>>>>>>> to allow the user to control their protection policies such as allow
>>>>>>> execution of critical 3rd party software that might violate memory
>>>>>>> protections.
>>>>>>>
>>>>>>> This RFC seeks your feedback regarding introducing an interface that
>>>>>>> allows dynamic configuration of memory protection settings.
>>>>>>>
>>>>>>> I would like to propose two options:
>>>>>>> 1. Describing the memory protection setting configuration in a 
>>>>>>> HOB that
>>>>>>> is produced by the platform.
>>>>>>> 2. Introducing a library class (e.g. MemoryProtectionLib) that 
>>>>>>> allows
>>>>>>> abstraction of the memory protection setting configuration data 
>>>>>>> source.
>>>>>>>
>>>>>>> In addition, I would like to know if the memory protection 
>>>>>>> FixedAtBuild
>>>>>>> PCDs currently in MdeModulePkg can be removed so we can move the
>>>>>>> configuration interface entirely to an option above.
>>>>>>>
>>>>>>> In any case, I would like the settings to be visible to environments
>>>>>>> such as Standalone MM where dynamic PCDs are not accessible.
>>>>>>>
>>>>>>> I am seeking your feedback on this proposal in preparation for 
>>>>>>> sending
>>>>>>> an edk2 patch series.
>>>>>>>
>>>>>>> -- 
>>>>>>> Taylor Beebe
>>>>>>> Software Engineer @ Microsoft
>>>>>
>>>>> -- 
>>>>> Taylor Beebe
>>>>> Software Engineer @ Microsoft
>>>
>>> -- 
>>> Taylor Beebe
>>> Software Engineer @ Microsoft
>>
>>
>> 
>>
>>

-- 
Taylor Beebe
Software Engineer @ Microsoft


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78460): https://edk2.groups.io/g/devel/message/78460
Mute This Topic: https://groups.io/mt/84392478/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-