[RFC] MemoryProtectionLib for Dynamic Memory Guard Settings

[RFC] MemoryProtectionLib for Dynamic Memory Guard Settings

[t]

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

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

[Taylor Beebe]

Note: I'll be accepting feedback on this until Friday after which I will 
submit a patch series.

On 7/22/2021 5:32 PM, Taylor Beebe via groups.io wrote:
> 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

Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings

[Wang, Jian J]

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@taylorbeebe.com>
> Sent: Friday, July 23, 2021 8:33 AM
> To: devel@edk2.groups.io
> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
> <ray.ni@intel.com>; Kumar, Rahul1 <Rahul1.Kumar@intel.com>;
> mikuback@linux.microsoft.com; Wang, Jian J <jian.j.wang@intel.com>; Wu,
> Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>;
> gaoliming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma, Maurice
> <maurice.ma@intel.com>; You, Benjamin <benjamin.you@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

Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings

[Taylor Beebe]

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@taylorbeebe.com>
>> Sent: Friday, July 23, 2021 8:33 AM
>> To: devel@edk2.groups.io
>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
>> <ray.ni@intel.com>; Kumar, Rahul1 <Rahul1.Kumar@intel.com>;
>> mikuback@linux.microsoft.com; Wang, Jian J <jian.j.wang@intel.com>; Wu,
>> Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>;
>> gaoliming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma, Maurice
>> <maurice.ma@intel.com>; You, Benjamin <benjamin.you@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

Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings

[Yao, Jiewen]

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@taylorbeebe.com>
> Sent: Friday, July 30, 2021 9:55 AM
> To: Wang, Jian J <jian.j.wang@intel.com>; devel@edk2.groups.io
> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>;
> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi, Dandan
> <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo
> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You, Benjamin
> <benjamin.you@intel.com>; Yao, Jiewen <jiewen.yao@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@taylorbeebe.com>
> >> Sent: Friday, July 23, 2021 8:33 AM
> >> To: devel@edk2.groups.io
> >> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
> >> <ray.ni@intel.com>; Kumar, Rahul1 <Rahul1.Kumar@intel.com>;
> >> mikuback@linux.microsoft.com; Wang, Jian J <jian.j.wang@intel.com>; Wu,
> >> Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>;
> >> gaoliming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma,
> Maurice
> >> <maurice.ma@intel.com>; You, Benjamin <benjamin.you@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

Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings

[Taylor Beebe]

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@taylorbeebe.com>
>> Sent: Friday, July 30, 2021 9:55 AM
>> To: Wang, Jian J <jian.j.wang@intel.com>; devel@edk2.groups.io
>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
>> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>;
>> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi, Dandan
>> <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo
>> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You, Benjamin
>> <benjamin.you@intel.com>; Yao, Jiewen <jiewen.yao@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@taylorbeebe.com>
>>>> Sent: Friday, July 23, 2021 8:33 AM
>>>> To: devel@edk2.groups.io
>>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
>>>> <ray.ni@intel.com>; Kumar, Rahul1 <Rahul1.Kumar@intel.com>;
>>>> mikuback@linux.microsoft.com; Wang, Jian J <jian.j.wang@intel.com>; Wu,
>>>> Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>;
>>>> gaoliming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma,
>> Maurice
>>>> <maurice.ma@intel.com>; You, Benjamin <benjamin.you@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

Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings

[Yao, Jiewen]

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@taylorbeebe.com>
> Sent: Friday, July 30, 2021 10:07 AM
> To: Yao, Jiewen <jiewen.yao@intel.com>; Wang, Jian J <jian.j.wang@intel.com>;
> devel@edk2.groups.io
> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>;
> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi, Dandan
> <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo
> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You, Benjamin
> <benjamin.you@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@taylorbeebe.com>
> >> Sent: Friday, July 30, 2021 9:55 AM
> >> To: Wang, Jian J <jian.j.wang@intel.com>; devel@edk2.groups.io
> >> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
> >> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>;
> >> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi,
> Dandan
> >> <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo
> >> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You,
> Benjamin
> >> <benjamin.you@intel.com>; Yao, Jiewen <jiewen.yao@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@taylorbeebe.com>
> >>>> Sent: Friday, July 23, 2021 8:33 AM
> >>>> To: devel@edk2.groups.io
> >>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
> >>>> <ray.ni@intel.com>; Kumar, Rahul1 <Rahul1.Kumar@intel.com>;
> >>>> mikuback@linux.microsoft.com; Wang, Jian J <jian.j.wang@intel.com>;
> Wu,
> >>>> Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>;
> >>>> gaoliming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma,
> >> Maurice
> >>>> <maurice.ma@intel.com>; You, Benjamin <benjamin.you@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

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

[Sean]

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@taylorbeebe.com>
>> Sent: Friday, July 30, 2021 10:07 AM
>> To: Yao, Jiewen <jiewen.yao@intel.com>; Wang, Jian J <jian.j.wang@intel.com>;
>> devel@edk2.groups.io
>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
>> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>;
>> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi, Dandan
>> <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo
>> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You, Benjamin
>> <benjamin.you@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@taylorbeebe.com>
>>>> Sent: Friday, July 30, 2021 9:55 AM
>>>> To: Wang, Jian J <jian.j.wang@intel.com>; devel@edk2.groups.io
>>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
>>>> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>;
>>>> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi,
>> Dandan
>>>> <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo
>>>> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You,
>> Benjamin
>>>> <benjamin.you@intel.com>; Yao, Jiewen <jiewen.yao@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@taylorbeebe.com>
>>>>>> Sent: Friday, July 23, 2021 8:33 AM
>>>>>> To: devel@edk2.groups.io
>>>>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
>>>>>> <ray.ni@intel.com>; Kumar, Rahul1 <Rahul1.Kumar@intel.com>;
>>>>>> mikuback@linux.microsoft.com; Wang, Jian J <jian.j.wang@intel.com>;
>> Wu,
>>>>>> Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>;
>>>>>> gaoliming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma,
>>>> Maurice
>>>>>> <maurice.ma@intel.com>; You, Benjamin <benjamin.you@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
> 
> 
> 
> 
> 

Re: [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@taylorbeebe.com>
>>> Sent: Friday, July 30, 2021 10:07 AM
>>> To: Yao, Jiewen <jiewen.yao@intel.com>; Wang, Jian J 
>>> <jian.j.wang@intel.com>;
>>> devel@edk2.groups.io
>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
>>> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>;
>>> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi, Dandan
>>> <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo
>>> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You, Benjamin
>>> <benjamin.you@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@taylorbeebe.com>
>>>>> Sent: Friday, July 30, 2021 9:55 AM
>>>>> To: Wang, Jian J <jian.j.wang@intel.com>; devel@edk2.groups.io
>>>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
>>>>> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>;
>>>>> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi,
>>> Dandan
>>>>> <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo
>>>>> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You,
>>> Benjamin
>>>>> <benjamin.you@intel.com>; Yao, Jiewen <jiewen.yao@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@taylorbeebe.com>
>>>>>>> Sent: Friday, July 23, 2021 8:33 AM
>>>>>>> To: devel@edk2.groups.io
>>>>>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
>>>>>>> <ray.ni@intel.com>; Kumar, Rahul1 <Rahul1.Kumar@intel.com>;
>>>>>>> mikuback@linux.microsoft.com; Wang, Jian J <jian.j.wang@intel.com>;
>>> Wu,
>>>>>>> Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>;
>>>>>>> gaoliming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma,
>>>>> Maurice
>>>>>>> <maurice.ma@intel.com>; You, Benjamin <benjamin.you@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

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

[Yao, Jiewen]

Hi Sean
That is excellent topic.

I agree with you that, one of most frequent asked question in the design meeting is: Should I use protocol or library? Sigh...

I added my personal thought below. I would like other people to comment, Mike Kinney, Andrew Fish, Liming Gao, who knows the history and EDKII design philosophy very well.

==========
Besides the specification difference you mentioned in previous email,

1) *Protocol* is between 2 modules in UEFI/SMM phase. It is used to pass data or abstract function.
2) *PPI* is similar to *Protocol*. But it is between 2 modules in PEI phase.

3) *HOB* is between 2 modules in different phase, to pass the data from one phase to the other. Such as PEI passing HOB to DXE, PEI passing HOB to SMM.
4) *Variable* is also between 2 modules in different phase. In addition, the data can be *NON_VOLATILE* and always be there across boot.
5) *GUID configuration table* is also between 2 modules in different phase, but it is limited from UEFI to OS. From function perspective, GUID HOB is same as GUID Config Table. The difference is that HOB is PI/OEM Firmware scope, while the GUID Config Table is UEFI/OS interface scope.

So far, above is the EDK-I design. However, two big issues existed in EDK-I.
A) The policy protocol. Everybody hated the policy protocol in EDKII, but everybody has to use it because there is no other choice. Everyone keeps increase the policy version and adds their own stuff, which make code hard to unify.
B) The library. In EDK-I, we had crazy library design - EfiDriverLib, EfiCommonLib, EfiRuntimeLib, EfiShellLib. It looked good at first glance. But when we link them together, it fails. 2 libraries may have same function name, but implement in different way. 2 libraries may have different function name, but implement same function. 

Those issues drove the two most important feature - PCD and Library design in EDK-II.

6) *PCD* is designed to abstract the OEM configuration data.
Static PCD means OEM can determine the value at build time.
Dynamic PCD means OEM need determine the value at runtime. (The implementation of PCD is still based upon PPI, Hob, and Protocol.)

7) A generic *library* is design to share common code in one place.
In addition, EDKII *library*serves another purpose: to abstract a set of common interface (as known as Library Class). That allows the OEM can replace the library implementation (as known as Library Instance) at build time without changing any code.

==========

Usually, we expose functions in a library instead of global data. (Well, there are exceptions such as gBS, gST, gRT, gSmst, which is well known pointers in history.)
I did not see too many cases to expose global data directly.

To compare UEFI protocol or C structure/class, I feel option 1 is similar to :
typedef struct {
Public:
	UINTN Data;
} CLASS_XXX.

While, option 2 is similar to :
typedef struct {
Private:
	UINTN Data;
Public:
	UINTN GetData ();
	VOID SetData (UINTN Data);
} CLASS_XXX.


I also see the similarity with https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/DebugLib.h, such as DebugAssertEnabled(), DebugPrintEnabled(), DebugCodeEnabled(), DebugClearMemoryEnabled(), DebugPrintLevelEnabled().
That is the reason I vote option 2.


Thank you
Yao Jiewen


> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean
> Sent: Saturday, July 31, 2021 2:42 AM
> To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Taylor Beebe
> <t@taylorbeebe.com>; Wang, Jian J <jian.j.wang@intel.com>
> Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Kumar,
> Rahul1 <rahul1.kumar@intel.com>; mikuback@linux.microsoft.com; Wu, Hao A
> <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>;
> gaoliming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma, Maurice
> <maurice.ma@intel.com>; You, Benjamin <benjamin.you@intel.com>
> Subject: Re: [edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory
> Guard Settings
> 
> 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@taylorbeebe.com>
> >> Sent: Friday, July 30, 2021 10:07 AM
> >> To: Yao, Jiewen <jiewen.yao@intel.com>; Wang, Jian J
> <jian.j.wang@intel.com>;
> >> devel@edk2.groups.io
> >> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
> >> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>;
> >> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi,
> Dandan
> >> <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo
> >> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You,
> Benjamin
> >> <benjamin.you@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@taylorbeebe.com>
> >>>> Sent: Friday, July 30, 2021 9:55 AM
> >>>> To: Wang, Jian J <jian.j.wang@intel.com>; devel@edk2.groups.io
> >>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
> >>>> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>;
> >>>> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi,
> >> Dandan
> >>>> <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo
> >>>> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You,
> >> Benjamin
> >>>> <benjamin.you@intel.com>; Yao, Jiewen <jiewen.yao@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@taylorbeebe.com>
> >>>>>> Sent: Friday, July 23, 2021 8:33 AM
> >>>>>> To: devel@edk2.groups.io
> >>>>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray
> >>>>>> <ray.ni@intel.com>; Kumar, Rahul1 <Rahul1.Kumar@intel.com>;
> >>>>>> mikuback@linux.microsoft.com; Wang, Jian J <jian.j.wang@intel.com>;
> >> Wu,
> >>>>>> Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>;
> >>>>>> gaoliming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma,
> >>>> Maurice
> >>>>>> <maurice.ma@intel.com>; You, Benjamin <benjamin.you@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
> >
> >
> >
> >
> >
> 
> 
> 
> 

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

[Ni, Ray]

I also vote "using HOB passing policy". This design helps the new bootloader/payload architecture.

EDKII library class design was a good design which mimics C++ class to provide same interface for:
1. different phases (PEI, DXE, runtime. E.g.: HobLib, PcdLib, MemoryAllocationLib)
2. different source of policy (e.g.: DebugLib.)
3. different optimization mechanism (e.g.: BaseMemoryLib)
4. more...

However, the extensive usage of lib class brings difficulty of understanding the code. There are so many instances of a library class and it's hard to know which one is being used by a certain module by just looking at the source code. (Sometimes even I need to build the code base and check the files in build directory to understand which lib instance is used for which module.)

It's a common issue in projects using OO programing language. But most of these projects are for application level needs and the app debugger is very easy to use. This is the difference between EDKII projects and other OO projects.

Thanks,
Ray

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean
Sent: Saturday, July 31, 2021 2:42 AM
To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Taylor Beebe <t@taylorbeebe.com>; Wang, Jian J <jian.j.wang@intel.com>
Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>; mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You, Benjamin <benjamin.you@intel.com>
Subject: Re: [edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings

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@taylorbeebe.com>
>> Sent: Friday, July 30, 2021 10:07 AM
>> To: Yao, Jiewen <jiewen.yao@intel.com>; Wang, Jian J 
>> <jian.j.wang@intel.com>; devel@edk2.groups.io
>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray 
>> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>; 
>> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi, 
>> Dandan <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo 
>> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You, 
>> Benjamin <benjamin.you@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@taylorbeebe.com>
>>>> Sent: Friday, July 30, 2021 9:55 AM
>>>> To: Wang, Jian J <jian.j.wang@intel.com>; devel@edk2.groups.io
>>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray 
>>>> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>; 
>>>> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi,
>> Dandan
>>>> <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo 
>>>> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You,
>> Benjamin
>>>> <benjamin.you@intel.com>; Yao, Jiewen <jiewen.yao@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@taylorbeebe.com>
>>>>>> Sent: Friday, July 23, 2021 8:33 AM
>>>>>> To: devel@edk2.groups.io
>>>>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, 
>>>>>> Ray <ray.ni@intel.com>; Kumar, Rahul1 <Rahul1.Kumar@intel.com>; 
>>>>>> mikuback@linux.microsoft.com; Wang, Jian J 
>>>>>> <jian.j.wang@intel.com>;
>> Wu,
>>>>>> Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>; 
>>>>>> gaoliming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma,
>>>> Maurice
>>>>>> <maurice.ma@intel.com>; You, Benjamin <benjamin.you@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
> 
> 
> 
> 
> 

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

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 12671 bytes --]



> On Aug 1, 2021, at 7:35 PM, Ni, Ray <ray.ni@intel.com> wrote:
> 
> I also vote "using HOB passing policy". This design helps the new bootloader/payload architecture.
> 
> EDKII library class design was a good design which mimics C++ class to provide same interface for:
> 1. different phases (PEI, DXE, runtime. E.g.: HobLib, PcdLib, MemoryAllocationLib)
> 2. different source of policy (e.g.: DebugLib.)
> 3. different optimization mechanism (e.g.: BaseMemoryLib)
> 4. more...
> 
> However, the extensive usage of lib class brings difficulty of understanding the code. There are so many instances of a library class and it's hard to know which one is being used by a certain module by just looking at the source code. (Sometimes even I need to build the code base and check the files in build directory to understand which lib instance is used for which module.)
> 

For our internal repos we set all our targets to build the build.log file for this reason. 

This is a quick way to find the library class instances in the repo…
$ git grep DebugLib -- *.inf | grep LIBRARY_CLASS
ArmPkg/Library/SemiHostingDebugLib/SemiHostingDebugLib.inf:19:  LIBRARY_CLASS                  = DebugLib|BASE SEC DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER
IntelFsp2Pkg/Library/BaseFspDebugLibSerialPort/BaseFspDebugLibSerialPort.inf:16:  LIBRARY_CLASS                  = DebugLib
MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf:26:  LIBRARY_CLASS                  = DebugLib|PEIM
MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf:19:  LIBRARY_CLASS                  = DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER SMM_CORE PEIM SEC PEI_CORE UEFI_APPLICATION UEFI_DRIVER
MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf:18:  LIBRARY_CLASS                  = DebugLib
MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf:19:  LIBRARY_CLASS                  = DebugLib
MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf:22:  LIBRARY_CLASS                  = DebugLib|DXE_RUNTIME_DRIVER
MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf:22:  LIBRARY_CLASS                  = DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER UEFI_APPLICATION UEFI_DRIVER
MdePkg/Library/UefiDebugLibDebugPortProtocol/UefiDebugLibDebugPortProtocol.inf:22:  LIBRARY_CLASS                  = DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER UEFI_APPLICATION UEFI_DRIVER
MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf:22:  LIBRARY_CLASS                  = DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER UEFI_APPLICATION UEFI_DRIVER
OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf:19:  LIBRARY_CLASS                  = DebugLib|PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER SMM_CORE DXE_SMM_DRIVER UEFI_DRIVER UEFI_APPLICATION
OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf:19:  LIBRARY_CLASS                  = DebugLib|SEC
OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPortNocheck.inf:18:  LIBRARY_CLASS                  = DebugLib
UnitTestFrameworkPkg/Library/Posix/DebugLibPosix/DebugLibPosix.inf:18:  LIBRARY_CLASS   = DebugLib|HOST_APPLICATION


Thanks,

Andrew Fish

> It's a common issue in projects using OO programing language. But most of these projects are for application level needs and the app debugger is very easy to use. This is the difference between EDKII projects and other OO projects.
> 
> Thanks,
> Ray
> 
> -----Original Message-----
> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>> On Behalf Of Sean
> Sent: Saturday, July 31, 2021 2:42 AM
> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io>; Yao, Jiewen <jiewen.yao@intel.com <mailto:jiewen.yao@intel.com>>; Taylor Beebe <t@taylorbeebe.com <mailto:t@taylorbeebe.com>>; Wang, Jian J <jian.j.wang@intel.com <mailto:jian.j.wang@intel.com>>
> Cc: Dong, Eric <eric.dong@intel.com <mailto:eric.dong@intel.com>>; Ni, Ray <ray.ni@intel.com <mailto:ray.ni@intel.com>>; Kumar, Rahul1 <rahul1.kumar@intel.com <mailto:rahul1.kumar@intel.com>>; mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com>; Wu, Hao A <hao.a.wu@intel.com <mailto:hao.a.wu@intel.com>>; Bi, Dandan <dandan.bi@intel.com <mailto:dandan.bi@intel.com>>; gaoliming@byosoft.com.cn <mailto:gaoliming@byosoft.com.cn>; Dong, Guo <guo.dong@intel.com <mailto:guo.dong@intel.com>>; Ma, Maurice <maurice.ma@intel.com <mailto:maurice.ma@intel.com>>; You, Benjamin <benjamin.you@intel.com <mailto:benjamin.you@intel.com>>
> Subject: Re: [edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings
> 
> 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@taylorbeebe.com>
>>> Sent: Friday, July 30, 2021 10:07 AM
>>> To: Yao, Jiewen <jiewen.yao@intel.com>; Wang, Jian J 
>>> <jian.j.wang@intel.com>; devel@edk2.groups.io
>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray 
>>> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>; 
>>> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi, 
>>> Dandan <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo 
>>> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You, 
>>> Benjamin <benjamin.you@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@taylorbeebe.com>
>>>>> Sent: Friday, July 30, 2021 9:55 AM
>>>>> To: Wang, Jian J <jian.j.wang@intel.com>; devel@edk2.groups.io
>>>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray 
>>>>> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>; 
>>>>> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi,
>>> Dandan
>>>>> <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo 
>>>>> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You,
>>> Benjamin
>>>>> <benjamin.you@intel.com>; Yao, Jiewen <jiewen.yao@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@taylorbeebe.com>
>>>>>>> Sent: Friday, July 23, 2021 8:33 AM
>>>>>>> To: devel@edk2.groups.io
>>>>>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, 
>>>>>>> Ray <ray.ni@intel.com>; Kumar, Rahul1 <Rahul1.Kumar@intel.com>; 
>>>>>>> mikuback@linux.microsoft.com; Wang, Jian J 
>>>>>>> <jian.j.wang@intel.com>;
>>> Wu,
>>>>>>> Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>; 
>>>>>>> gaoliming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma,
>>>>> Maurice
>>>>>>> <maurice.ma@intel.com>; You, Benjamin <benjamin.you@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
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> 
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 69578 bytes --]

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

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 10992 bytes --]



> On Aug 1, 2021, at 7:35 PM, Ni, Ray <ray.ni@intel.com> wrote:
> 
> I also vote "using HOB passing policy". This design helps the new bootloader/payload architecture.
> 
> EDKII library class design was a good design which mimics C++ class to provide same interface for:
> 1. different phases (PEI, DXE, runtime. E.g.: HobLib, PcdLib, MemoryAllocationLib)
> 2. different source of policy (e.g.: DebugLib.)
> 3. different optimization mechanism (e.g.: BaseMemoryLib)
> 4. more...
> 

I also like to think of this in terms on static and dynamic linking. For things that would be statically linked we use EDKII library classes. For dynamic linking we use Protocol/PPI and the required the coder to write code, vs having a dynamic linker resolve it for you. 

> However, the extensive usage of lib class brings difficulty of understanding the code. There are so many instances of a library class and it's hard to know which one is being used by a certain module by just looking at the source code. (Sometimes even I need to build the code base and check the files in build directory to understand which lib instance is used for which module.)
> 

The build log that can optionally be created by the tools is very useful for figuring all this kind of stuff out. Maybe we should come up with a best practice place to put those and turn it one for platforms that have scripts wrapping the build?

We could also build tooling to help with this? It is possible to add custom git commands to help in grepping code etc. So if people have ideas about tools we should discuss them….

Thanks,

Andrew Fish

> It's a common issue in projects using OO programing language. But most of these projects are for application level needs and the app debugger is very easy to use. This is the difference between EDKII projects and other OO projects.
> 
> Thanks,
> Ray
> 
> -----Original Message-----
> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>> On Behalf Of Sean
> Sent: Saturday, July 31, 2021 2:42 AM
> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io>; Yao, Jiewen <jiewen.yao@intel.com <mailto:jiewen.yao@intel.com>>; Taylor Beebe <t@taylorbeebe.com <mailto:t@taylorbeebe.com>>; Wang, Jian J <jian.j.wang@intel.com <mailto:jian.j.wang@intel.com>>
> Cc: Dong, Eric <eric.dong@intel.com <mailto:eric.dong@intel.com>>; Ni, Ray <ray.ni@intel.com <mailto:ray.ni@intel.com>>; Kumar, Rahul1 <rahul1.kumar@intel.com <mailto:rahul1.kumar@intel.com>>; mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com>; Wu, Hao A <hao.a.wu@intel.com <mailto:hao.a.wu@intel.com>>; Bi, Dandan <dandan.bi@intel.com <mailto:dandan.bi@intel.com>>; gaoliming@byosoft.com.cn <mailto:gaoliming@byosoft.com.cn>; Dong, Guo <guo.dong@intel.com <mailto:guo.dong@intel.com>>; Ma, Maurice <maurice.ma@intel.com <mailto:maurice.ma@intel.com>>; You, Benjamin <benjamin.you@intel.com <mailto:benjamin.you@intel.com>>
> Subject: Re: [edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings
> 
> 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@taylorbeebe.com>
>>> Sent: Friday, July 30, 2021 10:07 AM
>>> To: Yao, Jiewen <jiewen.yao@intel.com>; Wang, Jian J 
>>> <jian.j.wang@intel.com>; devel@edk2.groups.io
>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray 
>>> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>; 
>>> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi, 
>>> Dandan <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo 
>>> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You, 
>>> Benjamin <benjamin.you@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@taylorbeebe.com>
>>>>> Sent: Friday, July 30, 2021 9:55 AM
>>>>> To: Wang, Jian J <jian.j.wang@intel.com>; devel@edk2.groups.io
>>>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray 
>>>>> <ray.ni@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>; 
>>>>> mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>; Bi,
>>> Dandan
>>>>> <dandan.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo 
>>>>> <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.com>; You,
>>> Benjamin
>>>>> <benjamin.you@intel.com>; Yao, Jiewen <jiewen.yao@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@taylorbeebe.com>
>>>>>>> Sent: Friday, July 23, 2021 8:33 AM
>>>>>>> To: devel@edk2.groups.io
>>>>>>> Cc: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, 
>>>>>>> Ray <ray.ni@intel.com>; Kumar, Rahul1 <Rahul1.Kumar@intel.com>; 
>>>>>>> mikuback@linux.microsoft.com; Wang, Jian J 
>>>>>>> <jian.j.wang@intel.com>;
>>> Wu,
>>>>>>> Hao A <hao.a.wu@intel.com>; Bi, Dandan <dandan.bi@intel.com>; 
>>>>>>> gaoliming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma,
>>>>> Maurice
>>>>>>> <maurice.ma@intel.com>; You, Benjamin <benjamin.you@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
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> 
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 64231 bytes --]