Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings


Andrew Fish
 



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













Join devel@edk2.groups.io to automatically receive all group messages.