public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Wang, Jian J" <jian.j.wang@intel.com>
To: Taylor Beebe <t@taylorbeebe.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "spbrogan@outlook.com" <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" <mikuback@linux.microsoft.com>,
	"Wu, Hao A" <hao.a.wu@intel.com>,
	"Bi, Dandan" <dandan.bi@intel.com>,
	"gaoliming@byosoft.com.cn" <gaoliming@byosoft.com.cn>,
	"Dong, Guo" <guo.dong@intel.com>,
	"Ma, Maurice" <maurice.ma@intel.com>,
	"You, Benjamin" <benjamin.you@intel.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>
Subject: Re: [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings
Date: Thu, 29 Jul 2021 02:18:59 +0000	[thread overview]
Message-ID: <PH0PR11MB495166F6A667571DC7249135B6EB9@PH0PR11MB4951.namprd11.prod.outlook.com> (raw)
In-Reply-To: <d3233211-5c52-64e7-c3c9-75e0ea0b1bdd@taylorbeebe.com>

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: 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; Wang, Jian J <jian.j.wang@intel.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@intel.com>; You, Benjamin <benjamin.you@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

  reply	other threads:[~2021-07-29  2:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-23  0:32 [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings t
2021-07-29  2:18 ` Wang, Jian J [this message]
2021-07-30  1:54   ` Taylor Beebe
2021-07-30  1:57     ` Yao, Jiewen
2021-07-30  2:06       ` Taylor Beebe
2021-07-30  2:34         ` Yao, Jiewen
2021-07-30 18:42           ` [edk2-devel] " Sean
2021-07-30 22:25             ` Taylor Beebe
2021-07-31  1:38             ` Yao, Jiewen
2021-08-02  2:35             ` Ni, Ray
2021-08-02 19:56               ` Andrew Fish
2021-08-06 22:11               ` Andrew Fish

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=PH0PR11MB495166F6A667571DC7249135B6EB9@PH0PR11MB4951.namprd11.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox