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....@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
--
Taylor Beebe
Software Engineer @ Microsoft
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78460): https://edk2.groups.io/g/devel/message/78460
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]
-=-=-=-=-=-=-=-=-=-=-=-
