> On Aug 1, 2021, at 7:35 PM, Ni, Ray <ray...@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....@intel.com <mailto:jiewen....@intel.com>>; Taylor Beebe
> <t...@taylorbeebe.com <mailto:t...@taylorbeebe.com>>; Wang, Jian J
> <jian.j.w...@intel.com <mailto:jian.j.w...@intel.com>>
> Cc: Dong, Eric <eric.d...@intel.com <mailto:eric.d...@intel.com>>; Ni, Ray
> <ray...@intel.com <mailto:ray...@intel.com>>; Kumar, Rahul1
> <rahul1.ku...@intel.com <mailto:rahul1.ku...@intel.com>>;
> mikub...@linux.microsoft.com <mailto:mikub...@linux.microsoft.com>; Wu, Hao A
> <hao.a...@intel.com <mailto:hao.a...@intel.com>>; Bi, Dandan
> <dandan...@intel.com <mailto:dandan...@intel.com>>; gaolim...@byosoft.com.cn
> <mailto:gaolim...@byosoft.com.cn>; Dong, Guo <guo.d...@intel.com
> <mailto:guo.d...@intel.com>>; Ma, Maurice <maurice...@intel.com
> <mailto:maurice...@intel.com>>; You, Benjamin <benjamin....@intel.com
> <mailto:benjamin....@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....@intel.com>; Wang, Jian J
>>> <jian.j.w...@intel.com>; devel@edk2.groups.io
>>> Cc: spbro...@outlook.com; Dong, Eric <eric.d...@intel.com>; Ni, Ray
>>> <ray...@intel.com>; Kumar, Rahul1 <rahul1.ku...@intel.com>;
>>> mikub...@linux.microsoft.com; Wu, Hao A <hao.a...@intel.com>; Bi,
>>> Dandan <dandan...@intel.com>; gaolim...@byosoft.com.cn; Dong, Guo
>>> <guo.d...@intel.com>; Ma, Maurice <maurice...@intel.com>; You,
>>> Benjamin <benjamin....@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.w...@intel.com>; devel@edk2.groups.io
>>>>> Cc: spbro...@outlook.com; Dong, Eric <eric.d...@intel.com>; Ni, Ray
>>>>> <ray...@intel.com>; Kumar, Rahul1 <rahul1.ku...@intel.com>;
>>>>> mikub...@linux.microsoft.com; Wu, Hao A <hao.a...@intel.com>; Bi,
>>> Dandan
>>>>> <dandan...@intel.com>; gaolim...@byosoft.com.cn; Dong, Guo
>>>>> <guo.d...@intel.com>; Ma, Maurice <maurice...@intel.com>; You,
>>> Benjamin
>>>>> <benjamin....@intel.com>; Yao, Jiewen <jiewen....@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: spbro...@outlook.com; Dong, Eric <eric.d...@intel.com>; Ni,
>>>>>>> Ray <ray...@intel.com>; Kumar, Rahul1 <rahul1.ku...@intel.com>;
>>>>>>> mikub...@linux.microsoft.com; Wang, Jian J
>>>>>>> <jian.j.w...@intel.com>;
>>> Wu,
>>>>>>> Hao A <hao.a...@intel.com>; Bi, Dandan <dandan...@intel.com>;
>>>>>>> gaolim...@byosoft.com.cn; Dong, Guo <guo.d...@intel.com>; Ma,
>>>>> Maurice
>>>>>>> <maurice...@intel.com>; You, Benjamin <benjamin....@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
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78529): https://edk2.groups.io/g/devel/message/78529
Mute This Topic: https://groups.io/mt/84392478/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
