public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Taylor Beebe" <t@taylorbeebe.com>
To: Pedro Falcato <pedro.falcato@gmail.com>,
	Ard Biesheuvel <ardb@kernel.org>
Cc: devel@edk2.groups.io, Jian J Wang <jian.j.wang@intel.com>,
	Liming Gao <gaoliming@byosoft.com.cn>,
	Dandan Bi <dandan.bi@intel.com>,
	Ard Biesheuvel <ardb+tianocore@kernel.org>,
	Jiewen Yao <jiewen.yao@intel.com>,
	Jordan Justen <jordan.l.justen@intel.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Leif Lindholm <quic_llindhol@quicinc.com>,
	Sami Mujawar <sami.mujawar@arm.com>,
	Andrew Fish <afish@apple.com>, Ray Ni <ray.ni@intel.com>,
	Eric Dong <eric.dong@intel.com>,
	Rahul Kumar <rahul1.kumar@intel.com>,
	Guo Dong <guo.dong@intel.com>,
	Sean Rhodes <sean@starlabs.systems>,
	James Lu <james.lu@intel.com>, Gua Guo <gua.guo@intel.com>
Subject: Re: [edk2-devel] [PATCH 00/14] Implement Dynamic Memory Protections
Date: Mon, 17 Jul 2023 19:45:21 -0700	[thread overview]
Message-ID: <82fd0dfe-e746-bc37-1070-f248cef4c760@taylorbeebe.com> (raw)
In-Reply-To: <CAKbZUD1SxQES9HZ3KrEU=XQHCts=vj0Jd_WSUJ64t9ywoiA14Q@mail.gmail.com>



On 7/17/23 9:49 AM, Pedro Falcato wrote:
> On Mon, Jul 17, 2023 at 5:26 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> On Mon, 17 Jul 2023 at 18:15, Pedro Falcato <pedro.falcato@gmail.com> wrote:
>>>
>>> On Wed, Jul 12, 2023 at 12:53 AM Taylor Beebe <t@taylorbeebe.com> wrote:
>>>>
>>>> In the past, memory protection settings were configured via FixedAtBuild PCDs,
>>>> which resulted in a build-time configuration of memory mitigations. This
>>>> approach limited the flexibility of applying mitigations to the
>>>> system and made it difficult to update or adjust the settings post-build.
>>>
>>> How do you mitigate the possibility of an attack overwriting the
>>> dynamic configuration data (the HOBs)?
>>> It seems most dangerous to me to publish this sort of
>>> security-sensitive configuration knobs dynamically such that an
>>> attacker can change them.
>>>
>>
>> That is a very good point. One of the things I have on my TODO list
>> for the memory attributes PEI work is to remap HOB memory read-only
>> before entering DXE. They are conceptually read-only anyway when PEI
>> completes, so they should never be modified afterwards.
> 
> I agree, but it also seems that this patch set needs some sort of
> __ro_after_init capabilities. For example, in
> https://github.com/tianocore/edk2/pull/4566/commits/e485459b6efb1e49591c6f3011d9da14746c52bc#diff-02c0ef19d024b43162043efdd9ed95e0eef1653bcb5bef1e2f2b77587aee2622R101
> (DxeMemoryProtectionHobLibConstructor), a copy of this same HOB is
> made onto .data, while it should be RO-protected as well.
> With both the HOB list and this sort of __ro_after_init protected, the
> only remaining exploits would be to DMA over those pages (addressed by
> IOMMU, not in this scope), to remap those pages (requires ring 0
> access, therefore irrelevant) or to toggle some sort of WP-like bit
> (CR0.WP, other archs may have equivalents), which already bypasses
> most of the memory protections and therefore isn't all that concerning
> to me.
> 

Thank you both for you time and feedback.

Ard, do you think it's sufficient to use the Memory Attribute PPI to
mark HOB list memory as RO before handoff, or should the HOB list
memory be marked RO upon memory discovery and the PEI core
HOB logic be updated to manipulate protection attributes
with the PPI as it manipulates the HOB list?

-Taylor


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106976): https://edk2.groups.io/g/devel/message/106976
Mute This Topic: https://groups.io/mt/100090629/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2023-07-18  2:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11 23:52 [PATCH 00/14] Implement Dynamic Memory Protections Taylor Beebe
2023-07-11 23:52 ` [PATCH 01/14] MdeModulePkg: Add DXE and MM Memory Protection Settings Definitions Taylor Beebe
2023-07-11 23:52 ` [PATCH 02/14] MdeModulePkg: Add MemoryProtectionHobLib Definitions and NULL Libs Taylor Beebe
2023-07-11 23:52 ` [PATCH 03/14] MdeModulePkg: Add Phase-Specific MemoryProtectionHobLib Implementations Taylor Beebe
2023-07-11 23:52 ` [PATCH 04/14] OvmfPkg: Create the memory protection settings HOB Taylor Beebe
2023-07-11 23:52 ` [PATCH 05/14] ArmVirtPkg: Create " Taylor Beebe
2023-07-11 23:52 ` [PATCH 06/14] ArmPkg: Update to use memory protection HOB Taylor Beebe
2023-07-11 23:52 ` [PATCH 07/14] EmulatorPkg: " Taylor Beebe
2023-07-11 23:52 ` [PATCH 08/14] MdeModulePkg: " Taylor Beebe
2023-07-11 23:52 ` [PATCH 09/14] OvmfPkg: " Taylor Beebe
2023-07-11 23:52 ` [PATCH 10/14] UefiCpuPkg: " Taylor Beebe
2023-07-11 23:52 ` [PATCH 11/14] UefiPayloadPkg: " Taylor Beebe
2023-07-11 23:52 ` [PATCH 12/14] OvmfPkg: Delete Memory Protection PCDs Taylor Beebe
2023-07-11 23:52 ` [PATCH 14/14] MdeModulePkg: " Taylor Beebe
2023-07-11 23:52 ` Taylor Beebe
     [not found] ` <1770F551E2E594C0.16575@groups.io>
2023-07-12  0:01   ` [edk2-devel] " Taylor Beebe
2023-07-12 10:05 ` [PATCH 00/14] Implement Dynamic Memory Protections Gerd Hoffmann
2023-07-12 21:54   ` Taylor Beebe
2023-07-17 11:14     ` [edk2-devel] " Gerd Hoffmann
2023-07-17 16:15 ` Pedro Falcato
2023-07-17 16:25   ` Ard Biesheuvel
2023-07-17 16:49     ` Pedro Falcato
2023-07-18  2:45       ` Taylor Beebe [this message]
2023-07-18  6:11     ` Ni, Ray

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=82fd0dfe-e746-bc37-1070-f248cef4c760@taylorbeebe.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