From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp34.apple.com (rn-mailsvcp-ppex-lapp34.apple.com [17.179.253.43]) by mx.groups.io with SMTP id smtpd.web10.135.1628287906397047128 for ; Fri, 06 Aug 2021 15:11:46 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=M6zlRTbU; spf=pass (domain: apple.com, ip: 17.179.253.43, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp34.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp34.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 176M6mSa003563; Fri, 6 Aug 2021 15:11:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=xjHJfi+19rL8d3SZi5n7L8S2cgefF5LrUGL4XhcCpdI=; b=M6zlRTbUqlnhGH2+8VZ08BcPxxU/Vc9mgnXICpCHnzlzVyIEA1syB2v/WrfA/l7Y0xXN WO7sU46TYvqGNiFOe7ITEzPRi1r/BhRPenCt6GmTtSCFPv/l05141yehC+0utUgyLbYv OgXQ+wLfgSxDFaw6M6RwWVGOfTKtv/FpbsHWWBrW9yI3nte+y4kUFeSQTNkqKUqgMJs7 qPUmK6QCO58q9+vtb5+C4RH7APOSj8X44naytHtPJMJZ5VGqyxSq1lcyQGE/w/dfTifp mqfkkuoDbUoObzHPKqbUbuWG+w+MbnuCmzRs3bj5q/iYAniAjI4PDKn/qvxZMaECl16F pA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp34.rno.apple.com with ESMTP id 3a68bag0s0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 06 Aug 2021 15:11:30 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QXF00CKCUZ6UPC0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Fri, 06 Aug 2021 15:11:30 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QXF00300UVS5R00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 06 Aug 2021 15:11:30 -0700 (PDT) X-Va-A: X-Va-T-CD: 23e0047370634caa524bca754240c109 X-Va-E-CD: d0568e974606c78ffd56f46be4507df3 X-Va-R-CD: 4dc8a56e623649ab1227475d06f49f5b X-Va-CD: 0 X-Va-ID: c5b4aecf-23de-4f88-ac3e-69ab26c876f2 X-V-A: X-V-T-CD: 23e0047370634caa524bca754240c109 X-V-E-CD: d0568e974606c78ffd56f46be4507df3 X-V-R-CD: 4dc8a56e623649ab1227475d06f49f5b X-V-CD: 0 X-V-ID: 69d74ed2-9eeb-4ecc-830d-8f8443bcdb49 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-08-06_07:2021-08-06,2021-08-06 signatures=0 Received: from [17.235.56.92] (unknown [17.235.56.92]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QXF00KF3UZ4SG00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 06 Aug 2021 15:11:29 -0700 (PDT) From: "Andrew Fish" Message-id: MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings Date: Fri, 06 Aug 2021 15:11:27 -0700 In-reply-to: Cc: "spbrogan@outlook.com" , "Yao, Jiewen" , Taylor Beebe , "Wang, Jian J" , "Dong, Eric" , "Kumar, Rahul1" , "mikuback@linux.microsoft.com" , "Wu, Hao A" , "Bi, Dandan" , "gaoliming@byosoft.com.cn" , "Dong, Guo" , "Ma, Maurice" , "You, Benjamin" To: edk2-devel-groups-io , Ray Ni References: <5ffb8dce-8a33-537c-2019-ec4666854739@taylorbeebe.com> X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-08-06_07:2021-08-06,2021-08-06 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_31B0FEF4-C793-4A23-B2E7-D08F8DE7F2AE" --Apple-Mail=_31B0FEF4-C793-4A23-B2E7-D08F8DE7F2AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 1, 2021, at 7:35 PM, Ni, Ray wrote: >=20 > I also vote "using HOB passing policy". This design helps the new bootloa= der/payload architecture. >=20 > EDKII library class design was a good design which mimics C++ class to pr= ovide same interface for: > 1. different phases (PEI, DXE, runtime. E.g.: HobLib, PcdLib, MemoryAlloc= ationLib) > 2. different source of policy (e.g.: DebugLib.) > 3. different optimization mechanism (e.g.: BaseMemoryLib) > 4. more... >=20 I also like to think of this in terms on static and dynamic linking. For th= ings that would be statically linked we use EDKII library classes. For dyna= mic linking we use Protocol/PPI and the required the coder to write code, v= s having a dynamic linker resolve it for you.=20 > However, the extensive usage of lib class brings difficulty of understand= ing 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 fi= les in build directory to understand which lib instance is used for which m= odule.) >=20 The build log that can optionally be created by the tools is very useful fo= r 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 t= ools we should discuss them=E2=80=A6. 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 ver= y easy to use. This is the difference between EDKII projects and other OO p= rojects. >=20 > Thanks, > Ray >=20 > -----Original Message----- > From: devel@edk2.groups.io > On Behalf Of Sean > Sent: Saturday, July 31, 2021 2:42 AM > To: devel@edk2.groups.io ; Yao, Jiewen >; Taylor Beebe >; Wang, Jian J > > Cc: Dong, Eric >; Ni, Ra= y >; Kumar, Rahul1 >; mikuback@linux.microsoft.com <= mailto:mikuback@linux.microsoft.com>; Wu, Hao A >; Bi, Dandan >; gaoliming@byosoft.com.cn ; Dong= , Guo >; Ma, Maurice >; You, Benjamin > > Subject: Re: [edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory Gu= ard Settings >=20 > Jiewen, >=20 > **Slight rant** >=20 > I agree with libraries as an effective abstraction method. But I think t= here needs to be a broad discussion about the order of preference for metho= ds of abstraction. Today the edk2 code base is a mix and often there are n= umerous methods abstracting the same thing which leads to confusion, miscon= figuration, and error. >=20 > In the UEFI specification we have PPIs/Protocols/Events for functional ab= straction. We have variables, guided config tables, and HII for data abstr= action. >=20 > In the PI specification we add HOBs and PCDs for data abstractions. >=20 > Finally, in EDKII we add the library class concept and leverage it heavil= y for arch, phase, and platform/behavioral abstractions. >=20 > Without clear guidance for how and when to use the above it is hard to ke= ep code being developed by the larger community consistent. >=20 > **End** >=20 > I was leaning towards something closer to >=20 >>> Option 1:=20 > https://github.com/TaylorBeebe/edk2/tree/memory_protection_lib_2 >=20 > the HOB method and internally as we develop more code we are preferring H= OB and data abstractions more than functional abstraction. Data abstractio= ns can be used to control functional differences as well if needed. Data a= bstractions allow for easier validation and support diverse code environmen= ts. For example standalone MM and payloadpkg/payload concepts. Finally, d= ata abstractions break the need=20 > for a monolithic code base. But as you can see in option 1 it actually= =20 > uses a library class abstraction as well because no one wants to write th= e same code over and over again to get the HOB. The contract of the librar= y is just data but it still requires library mappings. Maybe these types o= f libraries need to be treated differently. >=20 > Anyway it would be great to hear from other members of the community arou= nd not just the memory protections RFC (this RFC) but around preferences fo= r abstraction techniques (pro/con). If an actual discussion starts it coul= d move to design meeting. >=20 > Thanks > Sean >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 7/29/2021 7:34 PM, Yao, Jiewen wrote: >> Thanks. Code talks better. >>=20 >> I prefer option 2, which is a generic way for abstraction. >>=20 >> And you may enable option 1 under the cover of option 2, just create a l= ib instance to get config from Hob. >>=20 >> Thank you >> Yao Jiewen >>=20 >>> -----Original Message----- >>> From: Taylor Beebe >>> Sent: Friday, July 30, 2021 10:07 AM >>> To: Yao, Jiewen ; Wang, Jian J=20 >>> ; devel@edk2.groups.io >>> Cc: spbrogan@outlook.com; Dong, Eric ; Ni, Ray=20 >>> ; Kumar, Rahul1 ;=20 >>> mikuback@linux.microsoft.com; Wu, Hao A ; Bi,=20 >>> Dandan ; gaoliming@byosoft.com.cn; Dong, Guo=20 >>> ; Ma, Maurice ; You,=20 >>> Benjamin >>> Subject: Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard=20 >>> Settings >>>=20 >>> Of course - here are a couple of rough drafts: >>>=20 >>> Option 1:=20 >>> https://github.com/TaylorBeebe/edk2/tree/memory_protection_lib_2 >>> Option 2:=20 >>> https://github.com/TaylorBeebe/edk2/tree/memory_protection_lib >>>=20 >>> On 7/29/2021 6:57 PM, Yao, Jiewen wrote: >>>> Hi >>>> Sorry, I am not able to follow the discussion. >>>>=20 >>>> Is there any sample or POC code to show the concept? >>>>=20 >>>>> -----Original Message----- >>>>> From: Taylor Beebe >>>>> Sent: Friday, July 30, 2021 9:55 AM >>>>> To: Wang, Jian J ; devel@edk2.groups.io >>>>> Cc: spbrogan@outlook.com; Dong, Eric ; Ni, Ray= =20 >>>>> ; Kumar, Rahul1 ;=20 >>>>> mikuback@linux.microsoft.com; Wu, Hao A ; Bi, >>> Dandan >>>>> ; gaoliming@byosoft.com.cn; Dong, Guo=20 >>>>> ; Ma, Maurice ; You, >>> Benjamin >>>>> ; Yao, Jiewen >>>>> Subject: Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard=20 >>>>> Settings >>>>>=20 >>>>> Thanks for your feedback, Jian. >>>>>=20 >>>>> In option 2, a most basic implementation would returning the=20 >>>>> current FixedAtBuild PCDs assuming they are kept. If they aren't,=20 >>>>> the library implementer could simply hard-code the return value for= =20 >>>>> each memory protection setting. >>>>>=20 >>>>> In option 1, the HOB would be published in pre-mem and I'm not an=20 >>>>> expert on exploiting the pre-mem environment. Jiewen may have more=20 >>>>> to say on >>> this. >>>>>=20 >>>>> -Taylor >>>>>=20 >>>>> 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=20 >>>>>> from me is the potential security holes introduced by the changes.= =20 >>>>>> According to your description, it allows 3rd party software to=20 >>>>>> violate memory protection >>> policy. >>>>>> I'd like to see more explanations on how to avoid it to be exploited= . >>>>>>=20 >>>>>> +Jiewen, what's current process to evaluate the security threat? >>>>>>=20 >>>>>> Regards, >>>>>> Jian >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Taylor Beebe >>>>>>> Sent: Friday, July 23, 2021 8:33 AM >>>>>>> To: devel@edk2.groups.io >>>>>>> Cc: spbrogan@outlook.com; Dong, Eric ; Ni,=20 >>>>>>> Ray ; Kumar, Rahul1 ;=20 >>>>>>> mikuback@linux.microsoft.com; Wang, Jian J=20 >>>>>>> ; >>> Wu, >>>>>>> Hao A ; Bi, Dandan ;=20 >>>>>>> gaoliming@byosoft.com.cn; Dong, Guo ; Ma, >>>>> Maurice >>>>>>> ; You, Benjamin >>>>>>> Subject: [RFC] MemoryProtectionLib for Dynamic Memory Guard=20 >>>>>>> Settings >>>>>>>=20 >>>>>>> Current memory protection settings rely on FixedAtBuild PCD=20 >>>>>>> values (minus PcdSetNxForStack). Because of this, the memory=20 >>>>>>> protection configuration interface is fixed in nature. Cases=20 >>>>>>> arise in which memory protections might need to be adjusted=20 >>>>>>> between boots (if platform design >>>>>>> allows) to avoid disabling a system. For example, platforms might= =20 >>>>>>> choose to allow the user to control their protection policies=20 >>>>>>> such as allow execution of critical 3rd party software that might= =20 >>>>>>> violate memory protections. >>>>>>>=20 >>>>>>> This RFC seeks your feedback regarding introducing an interface=20 >>>>>>> that allows dynamic configuration of memory protection settings. >>>>>>>=20 >>>>>>> I would like to propose two options: >>>>>>> 1. Describing the memory protection setting configuration in a=20 >>>>>>> HOB that is produced by the platform. >>>>>>> 2. Introducing a library class (e.g. MemoryProtectionLib) that=20 >>>>>>> allows abstraction of the memory protection setting configuration d= ata source. >>>>>>>=20 >>>>>>> In addition, I would like to know if the memory protection=20 >>>>>>> FixedAtBuild PCDs currently in MdeModulePkg can be removed so we=20 >>>>>>> can move the configuration interface entirely to an option above. >>>>>>>=20 >>>>>>> In any case, I would like the settings to be visible to=20 >>>>>>> environments such as Standalone MM where dynamic PCDs are not acces= sible. >>>>>>>=20 >>>>>>> I am seeking your feedback on this proposal in preparation for=20 >>>>>>> sending an edk2 patch series. >>>>>>>=20 >>>>>>> -- >>>>>>> Taylor Beebe >>>>>>> Software Engineer @ Microsoft >>>>>=20 >>>>> -- >>>>> Taylor Beebe >>>>> Software Engineer @ Microsoft >>>=20 >>> -- >>> Taylor Beebe >>> Software Engineer @ Microsoft >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_31B0FEF4-C793-4A23-B2E7-D08F8DE7F2AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 1, 202= 1, at 7:35 PM, Ni, Ray <r= ay.ni@intel.com> wrote:

I also vote "usi= ng HOB passing policy". This design helps the new bootloader/payload archit= ecture.

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.: HobL= ib, PcdLib, MemoryAllocationLib)
2. different source of policy (e.g.: DebugLib.)
3. different optimization mechanism (e= .g.: BaseMemoryLib)
4. = more...


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

However, the extensive usa= ge of lib class brings difficulty of understanding the code. There are so m= any instances of a library class and it's hard to know which one is being u= sed 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 un= derstand 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 ou= t. 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 p= ossible to add custom git commands to help in grepping code etc. So if peop= le have ideas about tools we should discuss them=E2=80=A6.

Thanks,

Andrew Fish=

<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size:= 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; text-align: start; text-indent: 0px; text-transform= : none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px; text-decoration: none; float: none; display: inline !important;" class= =3D"">It's a common issue in projects using OO programing language. But mos= t 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@edk= 2.groups.io> On Behalf Of Sean
Sent: Saturday, July 31, 2021 2:42 AM
To: devel@edk2.groups.io; Yao, Jie= wen <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; Do= ng, Guo <guo.dong@intel.com>; Ma, Maurice = <maurice.ma@intel.com>; You, Benjamin &l= t;benjamin.you@intel.com>
Subject: Re: [edk2-devel] [RFC] Memory= ProtectionLib for Dynamic Memory Guard Settings

Jiewen,

**Slight rant**
<= br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 1= 2px; font-style: normal; font-variant-caps: normal; font-weight: normal; le= tter-spacing: normal; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0p= x; text-decoration: none;" class=3D"">I agree with libraries as an e= ffective abstraction method.  But I think there needs to be a broad di= scussion about the order of preference for methods of abstraction.  To= day the edk2 code base is a mix and often there are numerous methods abstra= cting the same thing which leads to confusion, misconfiguration, and error.=

In the UEFI specification we have PPIs/Protocols/Events fo= r functional abstraction.  We have variables, guided config tables, an= d HII for data abstraction.
In the PI specification we add = HOBs and PCDs for data abstractions.

Finally, in EDKII we a= dd the library class concept and leverage it heavily for arch, phase, and p= latform/behavioral abstractions.

Without clear guidance for= how and when to use the above it is hard to keep code being developed by t= he larger community consistent.

**End**

I w= as 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 p= referring 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 di= verse code environments.  For example standalone MM and payloadpkg/pay= load concepts.  Finally, data abstractions break the need 
for a monolithic code base.   But as you can se= e in option 1 it actually 
uses a library class = abstraction as well because no one wants to write the same code over and ov= er again to get the HOB.  The contract of the library is just data but= it still requires library mappings.  Maybe these types of libraries n= eed to be treated differently.

Anyway it would be great to = hear from other members of the community around not just the memory protect= ions 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. Cod= e talks better.

I prefer option 2, which is a = generic way for abstraction.

And you may enabl= e option 1 under the cover of option 2, just create a lib instance to get c= onfig from Hob.

Thank you
Yao Ji= ewen

----= -Original Message-----
From: Taylor Beebe <t@taylorbeebe.com>
Se= nt: Friday, July 30, 2021 10:07 AM
To: Yao, Jiewen <jiewen.yao@intel.com>; = Wang, Jian J 
<jian.j.wang@inte= l.com>; devel@edk= 2.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.m= icrosoft.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 &l= t;maurice.ma@intel.com>; You, 
Benjamin <benjam= in.you@intel.com>
Subject: Re: [RFC] MemoryProtectionL= ib for Dynamic Memory Guard 
Settings

Of course - here ar= e 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: Tay= lor Beebe <t@taylorbeebe.com>
Sent: Friday, July 30, 20= 21 9:55 AM
To: Wang, Jian J <jian.j.wang@intel.com>; de= vel@edk2.groups.io
Cc: spbrogan@outlook.com; Dong, Eric <e= ric.dong@intel.com>; Ni, Ray =
<ray.ni@intel.com>; Kumar, Rahul1 <rahul1.ku= mar@intel.com>; 
mikuback@linux.microsoft.com; Wu, Hao A <hao.a.wu@intel.com>= ; Bi,
Dandan
<danda= n.bi@intel.com>; gaoliming@byosoft.com.cn; Dong, Guo 
<guo.dong@intel.com>; M= a, Maurice <maurice.ma@intel.com>; You,
Benjamin
<benjamin.you@intel.com>; Yao, Jiewe= n <jiewen.yao@intel.com>
Subject: Re: [RFC] MemoryProte= ctionLib for Dynamic Memory Guard&nbs= p;
Settings

Thanks for yo= ur feedback, Jian.

In option 2, a most basic i= mplementation would returning the&nbs= p;
current FixedAtBuild PCDs assuming they are kept. I= f they aren't, 
the library implementer could simply hard-code the return value for 
each memory= protection setting.

In option 1, the HOB woul= d 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:1= 8 PM, Wang, Jian J wrote:
Thanks for the RFC. I'm not object to this idea. The only concern 
from me is the po= tential security holes introduced by the changes. 
According to your description, it a= llows 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 t= he security threat?

Regards,
Jia= n

-----Or= iginal Message-----
From: Taylor Beebe <t@taylorbeebe.com&= gt;
Sent: Friday, July 23, 2021 8:33 AM
To: dev= el@edk2.groups.io
Cc: spbrogan@outlook.com; Dong, Eric <er= ic.dong@intel.com>; Ni, 
Ray <ray.ni@intel.com>; Kumar, Rahul1 <Rahul1.Kum= ar@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&= gt;; 
gaoli= ming@byosoft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma,
Maurice
<maurice.ma@intel.com&g= t;; You, Benjamin <benjamin.you@intel.com>
Subject: [RF= C] MemoryProtectionLib for Dynamic Memory Guard 
Settings

Current memory protection settings rely on FixedAtBuild PCD 
values (minus PcdSetNxFo= rStack). Because of this, the memory&= nbsp;
protection configuration interface is fixed in n= ature. Cases 
arise in which memory protections might need to be adjusted 
between boots (if pl= atform design
allows) to avoid disabling a system. For exampl= e, 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. MemoryProt= ectionLib) that 
allows abstraction of the memory protection setting configuration dat= a source.

In addition, I would like to know if= the memory protection FixedAtBuild PCDs currently in MdeModulePkg can be removed so = we 
can mov= e the configuration interface entirely to an option above.
In any case, I would like the settings to be visible to 
environments suc= h as Standalone MM where dynamic PCDs are not accessible.
I am seeking your feedback on this proposal in preparation for<= span class=3D"Apple-converted-space"> 
sending an= edk2 patch series.

--
Taylor Be= ebe
Software Engineer @ Microsoft
=

--
Taylor Beebe
Sof= tware Engineer @ Microsoft

--
Taylor Beebe
Software Engineer @ Micr= osoft













--Apple-Mail=_31B0FEF4-C793-4A23-B2E7-D08F8DE7F2AE--