public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: edk2-devel-groups-io <devel@edk2.groups.io>
Cc: "Ard Biesheuvel" <ard.biesheuvel@arm.com>,
	"Jiewen Yao" <jiewen.yao@intel.com>,
	"Jordan Justen" <jordan.l.justen@intel.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: [PATCH 1/4] OvmfPkg/PlatformPei: don't track BS Code/Data in default MemTypeInfo HOB
Date: Fri,  8 May 2020 14:16:48 +0200	[thread overview]
Message-ID: <20200508121651.16045-2-lersek@redhat.com> (raw)
In-Reply-To: <20200508121651.16045-1-lersek@redhat.com>

In commit d42fdd6f8384 ("OvmfPkg: improve SMM comms security with adaptive
MemoryTypeInformation", 2020-03-12), we enabled the boot-to-boot tracking
of the usages of various UEFI memory types.

Both whitepapers listed in that commit recommend that BS Code/Data type
memory *not* be tracked. This recommendation was confirmed by Jiewen in
the following two messages as well:

[1] https://edk2.groups.io/g/devel/message/55741
    http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F97B579@shsmsx102.ccr.corp.intel.com

[2] https://edk2.groups.io/g/devel/message/55749
    http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F97BDC5@shsmsx102.ccr.corp.intel.com

While tracking BS Code/Data type memory has one benefit (it de-fragments
the UEFI memory map), the downsides outweigh it. Spikes in BS Data type
memory usage are not uncommon in particular, and they may have the
following consequences:

- such reboots during normal boot that look "spurious" to the end user,
  and have no SMM security benefit,

- a large BS Data record in MemoryTypeInformation may cause issues when
  the DXE Core tries to prime the according bin(s), but the system's RAM
  size has been reduced meanwhile.

Removing the BS Code/Data entries from MemoryTypeInformation leads to a
bit more fragmentation in the UEFI memory map, but that should be
harmless.

Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 OvmfPkg/PlatformPei/MemTypeInfo.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/OvmfPkg/PlatformPei/MemTypeInfo.c b/OvmfPkg/PlatformPei/MemTypeInfo.c
index 863c6f382680..8100a2db7d44 100644
--- a/OvmfPkg/PlatformPei/MemTypeInfo.c
+++ b/OvmfPkg/PlatformPei/MemTypeInfo.c
@@ -31,8 +31,6 @@ STATIC EFI_MEMORY_TYPE_INFORMATION mDefaultMemoryTypeInformation[] = {
   { EfiReservedMemoryType,  0x004 },
   { EfiRuntimeServicesData, 0x024 },
   { EfiRuntimeServicesCode, 0x030 },
-  { EfiBootServicesCode,    0x180 },
-  { EfiBootServicesData,    0xF00 },
   { EfiMaxMemoryType,       0x000 }
 };
 
-- 
2.19.1.3.g30247aa5d201



  reply	other threads:[~2020-05-08 12:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08 12:16 [PATCH 0/4] OvmfPkg/PlatformPei: rewrite MemTypeInfo HOB production logic Laszlo Ersek
2020-05-08 12:16 ` Laszlo Ersek [this message]
2020-05-15 17:55   ` [PATCH 1/4] OvmfPkg/PlatformPei: don't track BS Code/Data in default MemTypeInfo HOB Philippe Mathieu-Daudé
2020-05-08 12:16 ` [PATCH 2/4] OvmfPkg/PlatformPei: rewrite MemTypeInfo HOB production logic Laszlo Ersek
2020-05-08 12:16 ` [PATCH 3/4] OvmfPkg/PlatformPei: extract memory type info defaults to PCDs Laszlo Ersek
2020-05-15 17:40   ` Philippe Mathieu-Daudé
2020-05-08 12:16 ` [PATCH 4/4] OvmfPkg/PlatformPei: increase memory type info defaults Laszlo Ersek
2020-05-12 15:19 ` [edk2-devel] [PATCH 0/4] OvmfPkg/PlatformPei: rewrite MemTypeInfo HOB production logic Laszlo Ersek
2020-05-15 10:10   ` Laszlo Ersek
2020-05-15 17:19 ` Ard Biesheuvel
2020-05-18 16:09 ` [edk2-devel] " Laszlo Ersek

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=20200508121651.16045-2-lersek@redhat.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