public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Dionna Glaze" <dionnaglaze@google.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: devel@edk2.groups.io, dave.hansen@linux.intel.com,
	 Jiewen <jiewen.yao@intel.com>,
	"Shutemov, Kirill" <kirill.shutemov@intel.com>
Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory behavior
Date: Fri, 13 Jan 2023 10:23:40 -0800	[thread overview]
Message-ID: <CAAH4kHa1WU_6505fYyvp=06RGyPoh_-Do++7oib=T23hEgy9ug@mail.gmail.com> (raw)
In-Reply-To: <0918b9db-c949-75ce-a24e-f12f03865938@intel.com>

> Kirill's _initial_ patch does #1.  If anyone desperately wants #2, they
> have mechanisms available to make a kernel with only #1 approximate #2.
> A user on that kernel could allocate and memset()ing a bunch of memory.
> Or, they could have a firmware stub accept the memory before booting the
> real kernel.
>
> It also doesn't rule out having a runtime knob or a boot parameter
> implement #2.  It's not a lot of code, but it involves new ABI.
>

The new ABI is the safety problem. Without the new code, you have
firmware that makes all but 3 GiB of memory unusable because it's
classified as an unknown type.

> However, *NONE* of this points me in the direction of saying that we
> should have an OS/firmware protocol to negotiate whether the firmware or
> OS does page acceptance other than the existing UEFI memory map bit.

We know of distributions that are going to release SEV-SNP support
without unaccepted memory support, and in so doing, tie the firmware's
hands in trying to maintain safe behavior through a required default
behavior of accepting all memory without explicit information from the
OS in the form of this protocol. TDX support may also get released
this way due to unexpected requirements from the linux community that
push back Kirill's patches. They still haven't been thoroughly
reviewed by a memory system expert, IIRC.

-- 
-Dionna Glaze, PhD (she/her)

  reply	other threads:[~2023-01-13 18:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13  0:14 [PATCH v9 0/4] Add safe unaccepted memory behavior Dionna Glaze
2023-01-13  0:14 ` [PATCH v9 1/4] OvmfPkg: Introduce CocoDxe driver Dionna Glaze
2023-01-13  0:14 ` [PATCH v9 2/4] MdePkg: Introduce the MemoryAcceptance protocol Dionna Glaze
2023-01-13  0:14 ` [PATCH v9 3/4] OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe Dionna Glaze
2023-01-13  0:14 ` [PATCH v9 4/4] OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted Dionna Glaze
2023-01-13  3:46 ` [PATCH v9 0/4] Add safe unaccepted memory behavior Yao, Jiewen
2023-01-13  7:18   ` [edk2-devel] " Gerd Hoffmann
2023-01-13  7:32     ` Yao, Jiewen
2023-01-13  9:32       ` Ard Biesheuvel
2023-01-13 11:11         ` Yao, Jiewen
2023-01-13 11:24           ` Ard Biesheuvel
2023-01-13 11:44             ` Yao, Jiewen
2023-01-13 12:00               ` Ard Biesheuvel
2023-01-13 16:00               ` dave.hansen
2023-01-13 17:06                 ` Dionna Glaze
2023-01-13 17:57                   ` Dave Hansen
2023-01-13 18:23                     ` Dionna Glaze [this message]
2023-01-13 18:34                       ` Dave Hansen
2023-01-16 10:28                         ` Gerd Hoffmann
2023-01-24 22:42                           ` Lendacky, Thomas
2023-01-24 22:46                             ` Dave Hansen
2023-01-25  9:01                             ` Ard Biesheuvel
2023-01-25  9:18                               ` Gerd Hoffmann
2023-01-25 11:44                                 ` Ard Biesheuvel
2023-01-25 12:10                                   ` Gerd Hoffmann
2023-01-25 14:52                                     ` Ard Biesheuvel
2023-01-25 16:56                                       ` Yao, Jiewen

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='CAAH4kHa1WU_6505fYyvp=06RGyPoh_-Do++7oib=T23hEgy9ug@mail.gmail.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