From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.apple.com [17.179.253.49]) by mx.groups.io with SMTP id smtpd.web11.2842.1627934237297559002 for ; Mon, 02 Aug 2021 12:57:17 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=APAutjRE; spf=pass (domain: apple.com, ip: 17.179.253.49, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 172Jq5NZ024827; Mon, 2 Aug 2021 12:57:02 -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=hFxgE+re2jv9UgzxX41xSnVoBY7C6OCyWfgUcCfACyQ=; b=APAutjREnAES6IMdAPCUaz7JaebC9yvtlG/0sFg87qKQAi8Rlnwej5/sbBD6nFzcuUhT iQzkjIHvzS1O/IM257/9BixEjpUBb8sg+0sbHFaTGeUq88TCKZtNTnZjtfx+dLUabX4g qEM/lpNVYJy83/zuayMezVALdRiE2mT/Tk5yr7BjsTLZ3PbMCJLJYzNKKit9AlDi7BME 1ZWdo/I+Ic4HKFeVjCAo2VFewY+eZNitzyYFQ8RtewuOm7GG0W0PoewNILk1XGTHOxP+ cn33Eg7/lQ7ox4jkoHBljvpZauMxWnZjTw5pKlKhWNSkJPuB4oP/jFE1uV7hQHD1emBP lg== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 3a5te1q069-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 02 Aug 2021 12:57:02 -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-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QX8009OJA320440@rn-mailsvcp-mta-lapp02.rno.apple.com>; Mon, 02 Aug 2021 12:57:02 -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 <0QX800M009ZQIP00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 02 Aug 2021 12:57:02 -0700 (PDT) X-Va-A: X-Va-T-CD: 04619f74f9efdf6774a6b133346de527 X-Va-E-CD: d0568e974606c78ffd56f46be4507df3 X-Va-R-CD: 4dc8a56e623649ab1227475d06f49f5b X-Va-CD: 0 X-Va-ID: f21b7332-e14f-48f0-96fc-c6007621de5f X-V-A: X-V-T-CD: 04619f74f9efdf6774a6b133346de527 X-V-E-CD: d0568e974606c78ffd56f46be4507df3 X-V-R-CD: 4dc8a56e623649ab1227475d06f49f5b X-V-CD: 0 X-V-ID: 6dbddbd8-55f8-482f-803e-ce697f058f87 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-08-02_07:2021-08-02,2021-08-02 signatures=0 Received: from [17.235.10.84] (unknown [17.235.10.84]) 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 <0QX800R1HA2ZCU00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 02 Aug 2021 12:57:01 -0700 (PDT) From: "Andrew Fish" Message-id: <7260AED0-93DD-4894-9B11-C5547451F194@apple.com> 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: Mon, 02 Aug 2021 12:56:59 -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@intel.com 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-02_07:2021-08-02,2021-08-02 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_1ADBBB04-FDDA-4975-A6FB-E9B09FEA6ED9" --Apple-Mail=_1ADBBB04-FDDA-4975-A6FB-E9B09FEA6ED9 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 bootlo= ader/payload architecture. >=20 > EDKII library class design was a good design which mimics C++ class to p= rovide same interface for: > 1. different phases (PEI, DXE, runtime. E.g.: HobLib, PcdLib, MemoryAllo= cationLib) > 2. different source of policy (e.g.: DebugLib.) > 3. different optimization mechanism (e.g.: BaseMemoryLib) > 4. more... >=20 > However, the extensive usage of lib class brings difficulty of understan= ding 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 f= iles in build directory to understand which lib instance is used for which = module.) >=20 For our internal repos we set all our targets to build the build.log file = for this reason.=20 This is a quick way to find the library class instances in the repo=E2=80= =A6 $ git grep DebugLib -- *.inf | grep LIBRARY_CLASS ArmPkg/Library/SemiHostingDebugLib/SemiHostingDebugLib.inf:19: LIBRARY_CL= ASS =3D DebugLib|BASE SEC DXE_CORE DXE_DRIVER DXE_RUNTIME_= DRIVER DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER IntelFsp2Pkg/Library/BaseFspDebugLibSerialPort/BaseFspDebugLibSerialPort.i= nf:16: LIBRARY_CLASS =3D DebugLib MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf:26: LIBR= ARY_CLASS =3D DebugLib|PEIM MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportSt= atusCode.inf:19: LIBRARY_CLASS =3D DebugLib|DXE_CORE DXE_= DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER SMM_CORE PEIM SEC PEI_CORE UEFI_AP= PLICATION UEFI_DRIVER MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf:18: LIBRARY_CLASS = =3D DebugLib MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf:19: LIBR= ARY_CLASS =3D DebugLib MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.i= nf:22: LIBRARY_CLASS =3D DebugLib|DXE_RUNTIME_DRIVER MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf:22: LIBRARY_CLAS= S =3D DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER UEFI= _APPLICATION UEFI_DRIVER MdePkg/Library/UefiDebugLibDebugPortProtocol/UefiDebugLibDebugPortProtocol= .inf:22: LIBRARY_CLASS =3D DebugLib|DXE_CORE DXE_DRIVER D= XE_RUNTIME_DRIVER UEFI_APPLICATION UEFI_DRIVER MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf:22: LIBRARY_CLAS= S =3D DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER UEFI= _APPLICATION UEFI_DRIVER OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf:19: LIB= RARY_CLASS =3D 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 =3D DebugLib|SEC OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPortNocheck.in= f:18: LIBRARY_CLASS =3D DebugLib UnitTestFrameworkPkg/Library/Posix/DebugLibPosix/DebugLibPosix.inf:18: LI= BRARY_CLASS =3D DebugLib|HOST_APPLICATION Thanks, Andrew Fish > It's a common issue in projects using OO programing language. But most o= f these projects are for application level needs and the app debugger is ve= ry easy to use. This is the difference between EDKII projects and other OO = projects. >=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, R= ay >; Kumar, Rahul1 >; mikuback@linux.microsoft.com = ; Wu, Hao A >; Bi, Dandan >; gaoliming@byosoft.com.cn ; Don= g, Guo >; Ma, Maurice >; You, Benjamin > > Subject: Re: [edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory G= uard Settings >=20 > Jiewen, >=20 > **Slight rant** >=20 > 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 meth= ods of abstraction. Today the edk2 code base is a mix and often there are = numerous methods abstracting the same thing which leads to confusion, misco= nfiguration, and error. >=20 > In the UEFI specification we have PPIs/Protocols/Events for functional a= bstraction. We have variables, guided config tables, and HII for data abst= raction. >=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 heavi= ly for arch, phase, and platform/behavioral abstractions. >=20 > Without clear guidance for how and when to use the above it is hard to k= eep 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 = HOB and data abstractions more than functional abstraction. Data abstracti= ons can be used to control functional differences as well if needed. Data = abstractions allow for easier validation and support diverse code environme= nts. For example standalone MM and payloadpkg/payload concepts. Finally, = data 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 t= he same code over and over again to get the HOB. The contract of the libra= ry is just data but it still requires library mappings. Maybe these types = of libraries need to be treated differently. >=20 > Anyway it would be great to hear from other members of the community aro= und not just the memory protections RFC (this RFC) but around preferences f= or abstraction techniques (pro/con). If an actual discussion starts it cou= ld 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 = lib 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 exploite= d. >>>>>>=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 = data 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 acce= ssible. >>>>>>>=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=_1ADBBB04-FDDA-4975-A6FB-E9B09FEA6ED9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 1, 20= 21, at 7:35 PM, Ni, Ray <= ray.ni@intel.com> wrote:

I also vote "us= ing HOB passing policy". This design helps the new bootloader/payload archi= tecture.

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.: Hob= Lib, 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 libr= ary 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 co= de base and check the files in build directory to understand which lib inst= ance is used for which module.)


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

This is a quick way to find the library class instances in the repo=E2=80= =A6
$=  git grep DebugLib -- *.inf | grep LIBRARY_CLASS<= /div>
ArmPkg/Library/SemiHostingDebu= gLib/SemiHostingDebugLib.inf:19:  LIBRARY_CLASS      &n= bsp;           =3D DebugLib|BASE SEC DXE_CORE DXE_= DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER
IntelFsp2Pkg/Library/BaseFsp= DebugLibSerialPort/BaseFspDebugLibSerialPort.inf:16:  LIBRARY_CLASS&nb= sp;                 =3D DebugLib
MdeModulePkg/Library/PeiD= ebugLibDebugPpi/PeiDebugLibDebugPpi.inf:26:  LIBRARY_CLASS   = ;               =3D DebugLib|PEIM=
MdeModulePkg/Library/PeiDxeDe= bugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf:19:  LIBRARY= _CLASS                  =3D De= bugLib|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               =   =3D DebugLib
Md= ePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf:19:  LI= BRARY_CLASS                  = =3D DebugLib
MdePkg/Li= brary/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf:22:&nbs= p; LIBRARY_CLASS                &nb= sp; =3D DebugLib|DXE_RUNTIME_DRIVER
MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf:22:&n= bsp; LIBRARY_CLASS                &= nbsp; =3D DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER UEFI_APPLICATION = UEFI_DRIVER
MdePkg/Libr= ary/UefiDebugLibDebugPortProtocol/UefiDebugLibDebugPortProtocol.inf:22:&nbs= p; LIBRARY_CLASS                &nb= sp; =3D DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER UEFI_APPLICATION UE= FI_DRIVER
MdePkg/Librar= y/UefiDebugLibStdErr/UefiDebugLibStdErr.inf:22:  LIBRARY_CLASS  &= nbsp;               =3D DebugLib|DXE_COR= E DXE_DRIVER DXE_RUNTIME_DRIVER UEFI_APPLICATION UEFI_DRIVER
OvmfPkg/Library/PlatformDebugLibIoPor= t/PlatformDebugLibIoPort.inf:19:  LIBRARY_CLASS      &n= bsp;           =3D DebugLib|PEI_CORE PEIM DXE_CORE= DXE_DRIVER DXE_RUNTIME_DRIVER SMM_CORE DXE_SMM_DRIVER UEFI_DRIVER UEFI_APP= LICATION
OvmfPkg/Librar= y/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf:19:  LIBRARY_CL= ASS                  =3D Debug= Lib|SEC
OvmfPkg/Librar= y/PlatformDebugLibIoPort/PlatformRomDebugLibIoPortNocheck.inf:18:  LIB= RARY_CLASS                  = =3D DebugLib
UnitTestF= rameworkPkg/Library/Posix/DebugLibPosix/DebugLibPosix.inf:18:  LIBRARY= _CLASS   =3D DebugLib|HOST_APPLICATION


Thanks,

Andrew Fish

It's a common issue in project= s using OO programing language. But most of these projects are for applicat= ion level needs and the app debugger is very easy to use. This is the diffe= rence 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: de= vel@edk2.groups.io; Yao, Jiewen <jiewen.yao= @intel.com>; Taylor Beebe <t@taylorbeebe.co= m>; Wang, Jian J <jian.j.wang@intel.com= >
Cc: Don= g, Eric <eric.dong@intel.com>; Ni, Ray &l= t;ray.ni@intel.com>; Kumar, Rahul1 <<= a href=3D"mailto:rahul1.kumar@intel.com" style=3D"font-family: Helvetica; f= ont-size: 12px; font-style: normal; font-variant-caps: normal; font-weight:= normal; letter-spacing: normal; orphans: auto; text-align: start; text-ind= ent: 0px; text-transform: none; white-space: normal; widows: auto; word-spa= cing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"= class=3D"">rahul1.kumar@intel.com>; mikuback@linux.microsof= t.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@int= el.com>; You, Benjamin <benjamin.you@i= ntel.com>
Subject: Re: [edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory Gua= rd 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 prefere= nce 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 specif= ication we have PPIs/Protocols/Events for functional abstraction.  We = have variables, guided config tables, and HII for data abstraction.<= 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"">
In the PI specification we add HOBs and PCDs for data abstractions= .

Finally, in EDKII we add the library class concept and le= verage it heavily for arch, phase, and platform/behavioral abstractions.

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

**End**

I was leaning towards something close= r to

Opti= on 1: 
https://github.com/TaylorBeebe/ed= k2/tree/memory_protection_lib_2

the HOB method and int= ernally as we develop more code we are preferring HOB and data abstractions= more than functional abstraction.  Data abstractions can be used to c= ontrol functional differences as well if needed.  Data abstractions al= low 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 co= de 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 co= mmunity around not just the memory protections RFC (this RFC) but around pr= eferences for abstraction techniques (pro/con).  If an actual discussi= on starts it could move to design meeting.

ThanksSean







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 optio= n 2, just create a lib instance to get config from Hob.

Thank you
Yao Jiewen

<= blockquote type=3D"cite" class=3D"">-----Original Message-----
From: Taylor Beebe <t@= taylorbeebe.com>
Sent: Friday, July 30, 2021 10:07 AM<= br class=3D"">To: Yao, Jiewen <jiewen.yao@intel.com>; Wang, Jian J 
<jian.j.wang@intel.com>; devel@edk2.groups.io
Cc: <= a href=3D"mailto:spbrogan@outlook.com" class=3D"">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 &l= t;dandan.bi@intel.com= >; gaoliming@byos= oft.com.cn; Dong, Guo 
<guo.do= ng@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/tre= e/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?<= br class=3D"">
-----Orig= inal 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
C= c: spbrogan@outlook.com; Dong, Eric <eric.dong@intel.com>; Ni, Ray 
<ray.ni@i= ntel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>; 
mikuback@linux.microsoft.= com; Wu, Hao A <hao.a.wu@intel.com>; Bi,
<= /blockquote>Dandan
<dandan.bi@intel.com>; gaoliming@byos= oft.com.cn; Dong, Guo <guo.dong@intel.com>; Ma, Maurice <maurice.ma@intel.co= m>; You,
Benjamin
=
&= lt;benjamin.you@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
Subject: Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard<= span class=3D"Apple-converted-space"> 
Settings
Thanks for your feedback, Jian.
<= br class=3D"">In option 2, a most basic implementation would returning the<= span class=3D"Apple-converted-space"> 
current Fi= xedAtBuild 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 n= ot an 
expe= rt on exploiting the pre-mem environment. Jiewen may have more 
to say on
this.

-Taylor<= br class=3D"">
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 introdu= ced by the changes. 
According to your description, it allows 3rd party software to 
violate memo= ry protection
policy.<= br class=3D"">
I'd like to see more expl= anations 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.microsof= t.com; Wang, Jian J 
<jian.j.wang@intel.com>;
Wu,
Hao A <hao.a.wu@intel.co= m>; Bi, Dandan <dandan.bi@intel.com>; 
gaoliming@byosoft.com.cn; Dong, Guo &l= t;guo.dong@intel.com>; Ma,
Mauri= ce
<maurice.ma@intel.com>; You, Benjamin <benjamin.yo= u@intel.com>
Subject: [RFC] MemoryProtectionLib for Dynami= c Memory Guard 
Settings

Current memory protection sett= ings rely on FixedAtBuild PCD 
values (minus PcdSetNxForStack). Because of this, the m= emory 
prot= ection configuration interface is fixed in nature. Cases 
arise in which memory protec= tions might need to be adjusted =
between boots (if platform design
allow= s) 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 s= oftware that might 
violate memory protections.

This RFC = seeks your feedback regarding introducing an interface 
that allows dynamic configurat= ion of memory protection settings.

I would lik= e to propose two options:
1. Describing the memory protection= setting configuration in a 
HOB that is produced by the platform.
2. In= troducing a library class (e.g. MemoryProtectionLib) that 
allows abstraction of the m= emory protection setting configuration data source.

In addition, I would like to know if the memory protection 
FixedAtBuild PCDs c= urrently in MdeModulePkg can be removed so we 
can move the configuration interface en= tirely to an option above.

In any case, I woul= d like the settings to be visible to&= nbsp;
environments such as Standalone MM where dynamic= PCDs are not accessible.

I am seeking your fe= edback on this proposal in preparation for 
sending an edk2 patch series.

--
Taylor Beebe
Software Engin= eer @ Microsoft

--Taylor Beebe
Software Engineer @ Microsoft

--
Taylor B= eebe
Software Engineer @ Microsoft













--Apple-Mail=_1ADBBB04-FDDA-4975-A6FB-E9B09FEA6ED9--