The signatures for event2 or event3 are now valid TCG SP800155 event
types. Fixes uncrustify formatting.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Gerd Hoffmann
Reviewed-by: Jiewen Yao
Signed-off-by: Dionna Glaze
---
OvmfPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c | 15 ++-
1 file changed, 10
The signatures for event2 or event3 are now valid TCG SP800155 event
types. Fixes uncrustify formatting.
Cc: Jiewen Yao
Cc: Rahul Kumar
Reviewed-by: Jiewen Yao
Signed-off-by: Dionna Glaze
---
SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 15 ++-
1 file changed, 10 insertions(+), 5
TCG PC Client Platform Firmware Profile 1.06 revision 52 of December
2023 added a new event signature and extended information about where a
reference measurement document for the firmware can be found.
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Reviewed-by: Jiewen Yao
In December 2023, the TCG published the PC Client Platform Firmware
Profile version 1.06 revision 52. This revision includes a new event
type for NIST SP 800-155 recommended signed BIOS reference measurements.
The new type allows for the event log auditor to find local or remote
copies of the
I had not passed some tests, apologies. I fixed the spacing issue and
build failure with too many )s in
https://github.com/tianocore/edk2/pull/5615. Shall I email a v4?
On Sun, May 5, 2024 at 8:28 PM Yao, Jiewen wrote:
>
> Hi Dionna
> I tried to create PR but I saw failure -
>
On Thu, May 2, 2024 at 8:59 AM Brian J. Johnson wrote:
>
> On 5/1/24 18:19, Dionna Glaze via groups.io wrote:
> > On Wed, May 1, 2024 at 11:12 AM Leif Lindholm via groups.io
> > wrote:
> >>
> >> On 2024-05-01 18:43, Michael D Kinney wrote:
> >>
The signatures for event2 or event3 are now valid TCG SP800155 event
types.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Gerd Hoffmann
Reviewed-by: Jiewen Yao
Signed-off-by: Dionna Glaze
---
OvmfPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff
The signatures for event2 or event3 are now valid TCG SP800155 event
types.
Cc: Jiewen Yao
Cc: Rahul Kumar
Reviewed-by: Jiewen Yao
Signed-off-by: Dionna Glaze
---
SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
TCG PC Client Platform Firmware Profile 1.06 revision 52 of December
2023 added a new event signature and extended information about where a
reference measurement document for the firmware can be found.
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Reviewed-By: Jiewen Yao
In December 2023, the TCG published the PC Client Platform Firmware
Profile version 1.06 revision 52. This revision includes a new event
type for NIST SP 800-155 recommended signed BIOS reference measurements.
The new type allows for the event log auditor to find local or remote
copies of the
On Wed, May 1, 2024 at 11:12 AM Leif Lindholm via groups.io
wrote:
>
> On 2024-05-01 18:43, Michael D Kinney wrote:
> > Hello,
> >
> > I would like to propose that TianoCore move all code review from email
> > based code reviews to GitHub Pull Requests based code reviews.
> >
> > The proposed
The signatures for event2 or event3 are now valid TCG SP800155 event
types.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Gerd Hoffmann
Reviewed-by: Jiewen Yao
Signed-off-by: Dionna Glaze
---
OvmfPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff
The signatures for event2 or event3 are now valid TCG SP800155 event
types.
Cc: Jiewen Yao
Cc: Rahul Kumar
Reviewed-by: Jiewen Yao
Signed-off-by: Dionna Glaze
---
SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
TCG PC Client Platform Firmware Profile 1.06 revision 52 of December
2023 added a new event signature and extended information about where a
reference measurement document for the firmware can be found.
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Dionna Glaze
---
In December 2023, the TCG published the PC Client Platform Firmware
Profile version 1.06 revision 52. This revision includes a new event
type for NIST SP 800-155 recommended signed BIOS reference measurements.
The new type allows for the event log auditor to find local or remote
copies of the
The signatures for event2 or event3 are now valid TCG SP800155 event
types.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Gerd Hoffmann
Signed-off-by: Dionna Glaze
---
OvmfPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
The signatures for event2 or event3 are now valid TCG SP800155 event
types.
Cc: Jiewen Yao
Cc: Rahul Kumar
Signed-off-by: Dionna Glaze
---
SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
In December 2023, the TCG published the PC Client Platform Firmware
Profile version 1.06 revision 52. This revision includes a new event
type for NIST SP 800-155 recommended signed BIOS reference measurements.
The new type allows for the event log auditor to find local or remote
copies of the
TCG PC Client Platform Firmware Profile 1.06 revision 52 of December
2023 added a new event signature and extended information about where a
reference measurement document for the firmware can be found.
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Dionna Glaze
---
On Mon, Mar 25, 2024 at 6:07 AM Mikko Ylinen
wrote:
>
> > >
> > > Looking at systemd-boot I see it will likewise not measure to both RTMR
> > > and vTPM, but with reversed priority (use vTPM not RTMR in case both are
> > > present).
> > >
> >
> > Interesting. Thanks for this report. We'll push
On Fri, Mar 22, 2024 at 1:52 AM Gerd Hoffmann wrote:
>
> On Fri, Mar 22, 2024 at 02:39:20AM +, Yao, Jiewen wrote:
> > Please aware that this option will cause potential security risk.
> >
> > In case that any the guest component only knows one of vTPM or RTMR,
> > and only extends one of vTPM
On Thu, Mar 21, 2024 at 9:59 AM qinkun Bao wrote:
>
> From: Qinkun Bao
>
> The UEFI v2.10 spec defines the protocol EFI_CC_MEASUREMENT_PROTOCOL
> to enable (for example) RTMR-based boot measurement for TDX VMs.
> With the current UEFI spec’s “should not” wording and EDK2
> implementation, TPM
This event should only trigger once. It should be idempotent, but the
allocation of the memory map itself is observable and can cause
ExitBootServices to fail with a modified map key.
Cc: Ard Biesheuvel
Cc: Thomas Lendacky
Cc: Erdem Aktas
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Min Xu
Cc:
>
> Adding the diff.
>
> diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> index 6391d1f775..df51c2c050 100644
> --- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> +++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> @@ -123,7 +123,7 @@ AcceptAllMemory (
> }
> }
>
> - gBS->FreePool
>
> Do you have any pointers on the IVARS service? Documentation, guest
> code, host code?
>
Agh, I thought for sure there was a public API for VM owners to view
or change their UEFI variables, but I guess not. It's an
instance-specific small data store for nonvolatile memory like vTPM
and UEFI
> Not solving the issue. Now, getting 4 calls. See below:
>
> ConvertPages: range 100 - 41AEFFF covers multiple entries
> ConvertPages: range 100 - 41AEFFF covers multiple entries
> Accepting all memory
> Accepting all memory
> Accepting all memory
> Accepting all memory
> EFI stub: ERROR:
I'm rather confused at the moment how our internal testing succeeds
given the premise of the protocol is to use the specified behavior
that the OS must call get_memory_map again if ebs fails with
efi_invalid_parameter, but upstream does not appear to do this.
If you're able to make progress by
>
> So, no memory is getting accepted. Questions below:
>
> - If no memory is getting accepted at all, should guest boot fail with
>below errors?
No, the guest should not error. EBS should return success on the
second call and permit progress.
> - Why unaccepted memory not being set in my
On Fri, Feb 10, 2023 at 5:56 AM Gupta, Pankaj wrote:
>
> On 2/9/2023 10:27 PM, Dionna Amalie Glaze wrote:
> > On Thu, Feb 9, 2023 at 8:52 AM Dionna Amalie Glaze
> > wrote:
> >>
> >>> With this patch I observe an issue where my Linux (6.2.0-rc7) guest
> >>> recur to Bootloader menu again. I am
On Thu, Feb 9, 2023 at 8:52 AM Dionna Amalie Glaze
wrote:
>
> > With this patch I observe an issue where my Linux (6.2.0-rc7) guest
> > recur to Bootloader menu again. I am testing this with SEV SNP (w/o
> > UPM). Also, guest don't have lazy memory acceptance support.
> >
>
> Thanks for the
> With this patch I observe an issue where my Linux (6.2.0-rc7) guest
> recur to Bootloader menu again. I am testing this with SEV SNP (w/o
> UPM). Also, guest don't have lazy memory acceptance support.
>
Thanks for the report. I'll try to reproduce it on our UEFI and if I'm
unable, then we'll
> >
> > This change is made given a request from Ard. The CC capability is not
> > applied to other system memory ranges that probably should also have
> > that capability, given that it's encrypted and accepted. I haven't
> > considered carefully where EFI_MEMORY_CPU_CRYPTO should be added to
> >
>
> efi: mem94: [Conventional| | |CC| | | | | | | | | | | ]
> range=[0x0001-0x00023fff] (5120MB)
>
> This does not have the cache capabilities one would expect for system
> memory, UC|WC|WT|WB.
>
> After this change, the same entry becomes
>
> efi: mem94:
The hard-coded attributes for the re-added memory space should instead
forward the replaced descriptor's capabilities, plus the
EFI_MEMORY_CPU_CRYPTO attribute.
Tested on Linux with efi=debug. Prior to this change, an 8GiB VM running
a kernel without unaccepted memory support shows this entry
> BTW, you need to add below guys in the CC list because they're the
> reviewers/maintainers of the pkgs.
>
> MdePkg:
> M: Michael D Kinney [mdkinney]
> M: Liming Gao [lgao4]
> R: Zhiguang Liu [LiuZhiguang001]
>
> MdeModulePkg
> M: Jian J Wang [jwang36]
> M: Liming Gao [lgao4]
>
CC'd,
The enumeration in MdePkg/Include/Pi/PiDxeCis.h has a duplicated entry,
so the 8th position in the list doesn't count as index 7. The value
EfiGcdMemoryTypeUnaccepted will have when added before
EfiGcdMemoryTypeMaximum will be 6.
Cc: Min M Xu
Cc: Jiewen Yao
Signed-off-by: Dionna Glaze
---
I was debugging some stuff with unaccepted memory, and noticed that
AddMemorySpace counted the unaccepted memory as "Unknown" because
"Unaccepte" is mGcdMemoryTypeNames[6] instead of
mGcdMemoryTypeNames[7].
> Shouldn't this check be inside the if () below? Or are all resources
> that start at or above 4 GiB guaranteed to be system memory?
>
> No need to resend - if needed, I can fix that up when applying.
>
Ah, yes that sounds right.
--
-Dionna Glaze, PhD (she/her)
-=-=-=-=-=-=-=-=-=-=-=-
Instead of eagerly accepting all memory in PEI, only accept memory under
the 4GB address. This allows a loaded image to use the
MEMORY_ACCEPTANCE_PROTOCOL to disable the accept behavior and indicate
that it can interpret the memory type accordingly.
This classification is safe since
This protocol implementation disables the accept-all-memory behavior
of the BeforeExitBootServices event this driver adds.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Cc: "Min M. Xu"
Cc: Andrew Fish
Cc: "Michael D. Kinney"
Signed-off-by:
The default behavior for unaccepted memory in SEV-SNP is to accept all
memory when ExitBootServices is called. An OS loader can use this
protocol to disable this behavior to assume responsibility for memory
acceptance and to affirm that the OS can handle the unaccepted memory
type.
Cc: Gerd
The added behavior is to accept all unaccepted memory at
ExitBootServices if the behavior is not disabled. This allows safe
upgrades for OS loaders to affirm their support for the unaccepted
memory type.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
We make eager memory acceptance the default behavior at
ExitBootServices for SEV-SNP machines by using the standard-enforced
behavior that if the call returns an error code, then the map key is
incorrect and the caller must re-call GetMemoryMap to ensure the
contents are correct.
Eager memory
> As Gerd and I discussed before, this protocol should be in OvmfPkg.
> Please move to
> https://github.com/tianocore/edk2/tree/master/OvmfPkg/Include/Protocol
>
Ah, I misinterpreted your response to Gerd's message. v11 will have it
moved. The CI seems to think I've redefined the protocol struct
>
> This driver is now both the producer and consumer of
> gEdkiiMemoryAcceptProtocolGuid.
>
> Are there cases where the protocol we locate here could be different
> from the one installed by this driver? If not, we can simplify this,
> and just call AmdSevMemoryAccept() directly.
>
Ah right.
Instead of eagerly accepting all memory in PEI, only accept memory under
the 4GB address. This allows a loaded image to use the
MEMORY_ACCEPTANCE_PROTOCOL to disable the accept behavior and indicate
that it can interpret the memory type accordingly.
This classification is safe since
This protocol implementation disables the accept-all-memory behavior
of the BeforeExitBootServices event this driver adds.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Cc: "Min M. Xu"
Cc: Andrew Fish
Cc: "Michael D. Kinney"
Signed-off-by:
The default behavior for unaccepted memory in SEV-SNP is to accept all
memory when ExitBootServices is called. An OS loader can use this
protocol to disable this behavior to assume responsibility for memory
acceptance and to affirm that the OS can handle the unaccepted memory
type.
This is a
The added behavior is to accept all unaccepted memory at
ExitBootServices if the behavior is not disabled. This allows safe
upgrades for OS loaders to affirm their support for the unaccepted
memory type.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
We make eager memory acceptance the default behavior at
ExitBootServices for SEV-SNP machines by using the standard-enforced
behavior that if the call returns an error code, then the map key is
incorrect and the caller must re-call GetMemoryMap to ensure the
contents are correct.
Eager memory
>
> Why do you call boot with a bootloader a legacy feature?
>
Gerd answered this about EBS called from the bootloader.
> > they'll only get a safe view of the memory map. I don't think it's right
> > to choose unsafe behavior for a legacy setup.
>
> Present memory map with unaccepted memory to
> > I still don't understand why we need to support every imaginable
> > combination of firmware, bootloader and OS. Unaccepted memory only
> > exists on a special kind of virtual machine, which provides very
> > little added value unless you opt into the security and attestation
> > features,
This patch depends on Kirill A. Shutemov's series
[PATCHv8 00/14] mm, x86/cc: Implement support for unaccepted memory
The UEFI v2.9 specification includes a new memory type to be used in
environments where the OS must accept memory that is provided from its
host. Before the introduction of this
> 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
>
This patch depends on Kirill A. Shutemov's series
[PATCHv8 00/14] mm, x86/cc: Implement support for unaccepted memory
The UEFI v2.9 specification includes a new memory type to be used in
environments where the OS must accept memory that is provided from its
host. Before the introduction of this
Thanks for your perspective, Dave. From what I understand,
distributions lag behind, user kernel configurations can be varied,
and Kirill's patch set is still untested with regards to memory
latency of workloads. We may yet see folks opt for a slow boot for
better latency. This protocol is for
Instead of eagerly accepting all memory in PEI, only accept memory under
the 4GB address. This allows a loaded image to use the
MEMORY_ACCEPTANCE_PROTOCOL to disable the accept behavior and indicate
that it can interpret the memory type accordingly.
This classification is safe since
This protocol implementation disables the accept-all-memory behavior
of the BeforeExitBootServices event this driver adds.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Cc: "Min M. Xu"
Cc: Andrew Fish
Cc: "Michael D. Kinney"
Signed-off-by:
The default behavior for unaccepted memory is to accept all memory
when ExitBootServices is called. An OS loader can use this protocol to
disable this behavior to assume responsibility for memory acceptance and
to affirm that the OS can handle the unaccepted memory type.
This is a candidate for
This driver is meant as a join point for all Confidential Compute
technologies to put shared behavior that doesn't belong anywhere else.
The first behavior added here is to accept all unaccepted memory at
ExitBootServices if the behavior is not disabled. This allows safe
upgrades for OS loaders
We make eager memory acceptance the default behavior at ExitBootServices
by using the standard-enforced behavior that if the call returns an
error code, then the map key is incorrect and the caller must re-call
GetMemoryMap to ensure the contents are correct.
Eager memory acceptance is
Thanks for your explanation and fastidiousness, Laszlo. Much appreciated.
On Thu, Jan 12, 2023 at 7:32 AM Laszlo Ersek wrote:
>
> On 1/12/23 14:38, Ard Biesheuvel wrote:
> > On Thu, 12 Jan 2023 at 13:24, Laszlo Ersek wrote:
> >>
> >> On 1/12/23 00:08, Di
On Thu, Nov 10, 2022 at 8:55 AM Kinney, Michael D
wrote:
>
> Hi Dionna,
>
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process
>
> I think you are at step 13. If you have not done so already, please update
> the
> commit messages with all the Reviewed-by and
On Tue, Dec 6, 2022 at 5:26 PM gaoliming wrote:
>
> Dionna:
> I add my comments below.
>
> > -邮件原件-
> > 发件人: devel@edk2.groups.io 代表 Dionna Glaze
> > via groups.io
> > 发送时间: 2022年11月9日 5:16
> > 收件人: devel@edk2.groups.io
> > 抄送: Dion
> Reviewed-by: Michael D Kinney
Great, thanks Michael. With all three patches reviewed/acked, does
that mean they get merged, or what else has to be done? I'm new to
this.
--
-Dionna Glaze, PhD (she/her)
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
>
> I can create a new patch that contains, the two Event definitions and the
> code that signals both events. I can use my patches that I already have and
> then add the code from your submission that signals the After Ready to Boot
> event to that.
>
> Rob
I think since Jiewen and Ard
ries with only Before Exit Boot Services is appropriate for your
> change.
>
> The After Ready To Boot can be in its own patch series.
>
> Best regards,
>
> Mike
>
> > -Original Message-
> > From: devel@edk2.groups.io On Behalf Of Dionna Glaze
> &
> I gave feedback about After Exit Boot Services event.
>
I saw no such event in the specification
> Why is an After Ready To Boot signal now part of this series?
>
I thought that's the event you meant, since its mantis number is 2042,
whereas before exit boot services is 2043. That fits the
>
> I am confused. I see patches related to ReadyToBoot and ExitBootServices and
> they mix what is in description and what is in code.
>
Will you please comment on the patches in question where the error is?
I don't follow what you're saying.
> I recommend you coordinate and put together a
> So how should we want to handle this. Leave yours in or leave mine in.
Given that I'm not particularly confident in how I've implemented the
after_ready_to_boot spec, and you haven't implemented it, I'm not
sure. I'm pursuing the before_exit_boot_services implementation to
solve a problem in
>
> This code signals the Before Exit Boot Services event at the beginning
> of the ExitBootServices() function. This gives all the rest of the
> code to prepare for the ExitBootServices event.
>
Hi Robert, I think we're both trying to do this at the same time. See
the patch series "SEV-SNP
The Uefi v2.9 specification adds this event group in section 3.1.7,
with its GUID defined in the Related Definitions section of
EFI_BOOT_SERVICES.CreateEventEx() in chapter 7.
Cc: "Michael D Kinney"
Cc: Ard Biesheuvel
Cc: Gerd Hoffman
Cc: Jiewen Yao
Signed-off-by: Dionna Glaze
---
Location of notification is has been specified in UEFI v2.9.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Cc: "Min M. Xu"
Cc: Andrew Fish
Cc: "Michael D. Kinney"
Cc: Ray Ni
Acked-by: Jiewen Yao
Signed-off-by: Dionna Glaze
---
Add EFI_EVENT_BEFORE_EXIT_BOOT_SERVICES_GUID
Add EFI_EVENT_GROUP_AFTER_READY_TO_BOOT
Both defined in UEFI standard v2.9.
Cc: Ard Biescheuvel
Cc: "Min M. Xu"
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Tom Lendacky
Cc: Jiewen Yao
Cc: Erdem Aktas
Signed-off-by: Dionna Glaze
---
From: Sophia Wolf
When a guest OS does not support unaccepted memory, the unaccepted
memory must be accepted before returning a memory map to the caller.
EfiMemoryAcceptProtocol is defined in MdePkg and is implemented /
Installed in AmdSevDxe for AMD SEV-SNP memory acceptance.
Cc: Gerd
This is the first half of the patch series
[PATCH v8 0/7] Add safe unaccepted memory behavior
These patches add SEV-SNP support for the MemoryAccept protocol, and
implement an already standardized mechanism for performing any actions
just before terminating the memory map.
We implement a
> The total time for memory accept is 4 part:
>1) vBIOS early phase, single thread accept
>2) vBIOS runtime phase, multi thread accept
>3) OS early phase, single thread accept
>4) OS runtime phase, multi thread accept
>
>We hope 1) is zero.
>And we are trying to balance between 2) and 3).
Do you
Location of notification is has been specified in UEFI v2.9.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Cc: "Min M. Xu"
Cc: Andrew Fish
Cc: "Michael D. Kinney"
Cc: Ray Ni
Acked-by: Jiewen Yao
Signed-off-by: Dionna Glaze
---
Event group as defined in UEFI standard v2.9.
Cc: Ard Biescheuvel
Cc: "Min M. Xu"
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Tom Lendacky
Cc: Jiewen Yao
Cc: Erdem Aktas
Acked-by: Jiewen Yao
Signed-off-by: Dionna Glaze
---
MdePkg/Include/Guid/EventGroup.h | 5 +
MdePkg/MdePkg.dec
From: Sophia Wolf
When a guest OS does not support unaccepted memory, the unaccepted
memory must be accepted before returning a memory map to the caller.
EfiMemoryAcceptProtocol is defined in MdePkg and is implemented /
Installed in AmdSevDxe for AMD SEV-SNP memory acceptance.
Cc: Gerd
This is the first half of the patch series
[PATCH v8 0/7] Add safe unaccepted memory behavior
These patches add SEV-SNP support for the MemoryAccept protocol, and
implement an already standardized mechanism for performing any actions
just before terminating the memory map.
We implement a
>
> BTW: Is there any data for AMD-SEV?
>
Earlier this year, I tried to make the lazy accept patches work for
SEV-SNP, but the boot would always crash in the Qemu try boot kernel
step IIRC:
https://github.com/AMDESE/ovmf/pull/4
Tom suggested accepting the first 4GiB and I didn't go back to try
On Tue, Nov 8, 2022 at 8:09 AM Yao, Jiewen wrote:
>
> Hi Tom/Dionna
> I think this patch is addressing
> https://bugzilla.tianocore.org/show_bug.cgi?id=3987.
>
> For patch 1~3, I am OK for the API which we already agreed, such as
> EfiMemoryAcceptProtocol and
>
> btw it still fails in CoreTerminateMemoryMap() with the current upstream
> kernel which is not aware of the lazy memory acceptance, is this
> something known? Thanks,
>
It wasn't known. I'll take a look. Thanks for the report.
--
-Dionna Glaze, PhD (she/her)
-=-=-=-=-=-=-=-=-=-=-=-
On Tue, Oct 25, 2022 at 5:23 PM Alexey Kardashevskiy wrote:
>
> Hi Dionna,
>
> Thanks for updating the tree, builds nicely now! However the VM's kernel
> does not boot - the guest kernel reports
>
> EFI stub: ERROR: exit_boot() failed!
>
> and hangs. I am not quite sure how it is supposed to work
Location of notification is has been specified in UEFI v2.9.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Cc: "Min M. Xu"
Cc: Andrew Fish
Cc: "Michael D. Kinney"
Cc: Ray Ni
Signed-off-by: Dionna Glaze
---
MdeModulePkg/Core/Dxe/DxeMain.inf
Instead of eagerly accepting all memory in PEI, only accept memory under
the 4GB address. This allows a loaded image to use the
MEMORY_ACCEPTANCE_PROTOCOL to disable the accept behavior and indicate
that it can interpret the memory type accordingly.
This classification is safe since
This protocol implementation disables the accept-all-memory behavior
of the BeforeExitBootServices event this driver adds.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Cc: "Min M. Xu"
Cc: Andrew Fish
Cc: "Michael D. Kinney"
Signed-off-by:
The default behavior for unaccepted memory is to accept all memory
when ExitBootServices is called. An OS loader can use this protocol to
disable this behavior to assume responsibility for memory acceptance and
to affirm that the OS can handle the unaccepted memory type.
This is a candidate for
This driver is meant as a join point for all Confidential Compute
technologies to put shared behavior that doesn't belong anywhere else.
The first behavior added here is to accept all unaccepted memory at
ExitBootServices if the behavior is not disabled. This allows safe
upgrades for OS loaders
Event group as defined in UEFI standard v2.9.
Cc: Ard Biescheuvel
Cc: "Min M. Xu"
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Tom Lendacky
Cc: Jiewen Yao
Cc: Erdem Aktas
Signed-off-by: Dionna Glaze
---
MdePkg/Include/Guid/EventGroup.h | 5 +
MdePkg/MdePkg.dec| 5 -
From: Sophia Wolf
When a guest OS does not support unaccepted memory, the unaccepted
memory must be accepted before returning a memory map to the caller.
EfiMemoryAcceptProtocol is defined in MdePkg and is implemented /
Installed in AmdSevDxe for AMD SEV-SNP memory acceptance.
Cc: Gerd
These seven patches build on the lazy-accept patch series
"Introduce Lazy-accept for Tdx guest"
by adding SEV-SNP support for the MemoryAccept protocol, and
importantly making eager memory acceptance the default behavior.
We implement a standardized event group from UEFI v2.9,
>
> Hey!
>
> Sorry if this was asked. I was wondering if this patchset is in some git repo
> which I pull from as I struggle to get a buildable tree by applying this
> patchset to whatever I can find.
>
> I tried https://github.com/deeglaze/edk2.git enable_umv7 but it does not
> build
> > Min:
> > I understand that they are for the different purpose and usage. But, their
> > protocol name are very similar.
> Yes. They do look very similar.
>
> > If there is no better protocol name, I will also be fine.
> Dionna, what's your thought?
>
The accept_all_unaccepted_memory name
> > I suppose that's true. Would you prefer volatile versions of
> > OsIndications/OsIndicationsSupported added to the spec, or this
> > proposed one-off toggle protocol? No specified global variables seem
> > overloadable with this duty.
> >
>
> No it would have to be a completely separate
> That assumes the variable is non-volatile, but I suppose we could use
> a volatile variable [other than OsIndications] as well.
>
I suppose that's true. Would you prefer volatile versions of
OsIndications/OsIndicationsSupported added to the spec, or this
proposed one-off toggle protocol? No
>
> Can OsIndicationsSupported UEFI variable provide the similar functionality?
>
Similar, but not the same. If we use a UEFI variable, its value will
persist across boots. This can be fine if you only boot one OS, but if
you have two where one supports unaccepted memory and the other
doesn't
Hi Abdul, I'm not a maintainer, just a contributor. I thought I'd pop
in with an observation though. I'm not seeing any diffs in these
emails. I'm not going to click a suspicious-looking link either.
Likely other folks have the same reservation. Have you read the
contributor guidelines on how to
> The name of EDKII_MEMORY_ACCEPT_PROTOCOL indicates it is only used in edk2.
Ah, yes I was basing my changes off probably a very old version of
TDVF's patches that used the EFI_ naming convention, so folks looking
at my branch might have been expecting that it'd be standardized.
Cool. Just the
1 - 100 of 164 matches
Mail list logo
