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 mea
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 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 for
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 signe
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
---
MdeP
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
b/Securi
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 a/OvmfPkg/Tcg/TdTcg2Dxe
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 signe
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
---
.../
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 a/SecurityPkg/Tcg/Tc
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 --gi
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 date
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
Signed-off-by
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 signe
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 a/SecurityPkg/Tcg/Tc
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 --gi
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:
> >>>
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 -
> https://github.com
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 signe
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
Signed-off-by
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 deletion
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 ins
I have a working stack with proposal 5. I was using a version of grub that
didn't use Linux's EFI handover protocol, and I wasn't signalling the
unaccepted memory behavior at the right place (before EBS).
Many thanks to everyone who contributed to this discussion and brought some
creative ideas to
These three 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.
For unaccepted memory to be enabled, we must know that the booted image
su
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 implementated /
Installed in AmdSevDxe for AMD SEV-SNP memory acceptance.
Cc: Gerd Hoffma
With the addition of the EfiUnacceptedMemory memory type, it is possible
the EFI-enlightened guests do not themselves support the new memory
type. This commit adds a dynamic Pcd that can be set to enable
unaccepted memory support before ExitBootServices is called.
The expected usage is to set the
Add a simple protocol that enables the use of the unaccepted memory
type. Must be called before ExitBootServices to be effective.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Signed-off-by: Dionna Glaze
---
MdeModulePkg/Core/Dxe/DxeMain.h
Ah yes, I did forget to include that patch. Will add to v2. I was just
setting the ResourceType to unaccepted and skipping the Prevalidate call in
PlatformPei if the start address is greater or equal to SIZE_4GB. That
seemed more self-contained than messing with PlatformInitLib. Would you
prefer th
These three 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.
For unaccepted memory to be enabled, we must know that the booted image
su
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 implementated /
Installed in AmdSevDxe for AMD SEV-SNP memory acceptance.
Cc: Gerd Hoffma
With the addition of the EfiUnacceptedMemory memory type, it is possible
the EFI-enlightened guests do not themselves support the new memory
type. This commit adds a dynamic Pcd that can be set to enable
unaccepted memory support before ExitBootServices is called.
The expected usage is to set the
Add a simple protocol that enables the use of the unaccepted memory
type. Must be called before ExitBootServices to be effective.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Signed-off-by: Dionna Glaze
---
MdeModulePkg/Core/Dxe/DxeMain.h
Instead of eagerly accepting all memory in PEI, only accept memory under
the 4GB address. This allows a loaded image to use the
ENABLE_UNACCEPTED_MEMORY_PROTOCOL to indicate that it can interpret the
memory type accordingly.
This classification is safe since ExitBootServices will accept and
reclas
>
> Shouldn't this have a v2 in the subject (same goes for patch 2/4)?
>
Yes. I'm upset that didn't happen. I used --subject="PATCHv2" in git
send-email, and editing the cover letter showed that all the other
emails would have PATCHv2 in the subject. Then I said to send the
emails and saw "PATCH "
These three 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.
For unaccepted memory to be enabled, we must know that the booted image
su
With the addition of the EfiUnacceptedMemory memory type, it is possible
the EFI-enlightened guests do not themselves support the new memory
type. This commit adds a dynamic Pcd that can be set to enable
unaccepted memory support before ExitBootServices is called.
The expected usage is to set the
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 Hoffmann
Add a simple protocol that enables the use of the unaccepted memory
type. Must be called before ExitBootServices to be effective.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Signed-off-by: Dionna Glaze
---
MdeModulePkg/Core/Dxe/DxeMain.h
Instead of eagerly accepting all memory in PEI, only accept memory under
the 4GB address. This allows a loaded image to use the
ENABLE_UNACCEPTED_MEMORY_PROTOCOL to indicate that it can interpret the
memory type accordingly.
This classification is safe since ExitBootServices will accept and
reclas
These three 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.
For unaccepted memory to be enabled, we must know that the booted image
su
This Pcd is used to toggle whether ExitBootServices should not accept
all unaccepted memory. It's the loaded image's responsibility to enable
support so that it doesn't get memory types it doesn't understand in its
memory map.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendack
The default value of PcdEnableUnacceptedMemory should be FALSE in order
for default safe behavior. If the next started image does not yet
understand UEFI v2.9's new memory type, then it's stuck with most of its
memory inaccessible.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Le
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 Hoffmann
With the addition of the EfiUnacceptedMemory memory type, it is possible
the EFI-enlightened guests do not themselves support the new memory
type. This commit uses the new PcdEnableUnacceptedMemory to enable
unaccepted memory support before ExitBootServices is called by not
accepting all unaccepted
Add a simple protocol that enables the use of the unaccepted memory
type. Must be called before ExitBootServices to be effective.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Signed-off-by: Dionna Glaze
---
MdeModulePkg/Core/Dxe/DxeMain.h
Instead of eagerly accepting all memory in PEI, only accept memory under
the 4GB address. This allows a loaded image to use the
ENABLE_UNACCEPTED_MEMORY_PROTOCOL to indicate that it can interpret the
memory type accordingly.
This classification is safe since ExitBootServices will accept and
reclas
>
> Can you explain a bit more why this PCD is needed?
>
I'll expand the comment further, but essentially we need a bit in the
firmware to persist from a call into a protocol to the eventual call
to ExitBootServices. If we needed offline persistence, then we'd need
to standardize a new bit in the
> The name PcdEnableUnacceptedMemory is a bit confusing imho. Could we
> rename this to PcdAcceptAllUnacceptedMemory or something like that?
>
Will do. Is the protocol name EnableUnacceptedMemory still acceptable
now that it's setting an AcceptAllUnacceptedMemory value to FALSE?
--
-Dionna Glaze
> Generally, we tend to rely on the DEC default for new PCDs if we're
> not deviating from it.
> If there is no specific reason to deviate from this here, I think we
> can drop this patch.
>
> Or is this also needed to declare them as the right type? In that
> case, I think you can drop the hunks t
> > +{
> > + MemEncryptSevSnpPreValidateSystemRam (
> > +StartAddress,
> > +EFI_SIZE_TO_PAGES (Size)
>
> Sorry, I forgot to ask this earlier in the series, but is StartAddress
> guaranteed to be page-aligned and Size a multiple of 4KB? Should there be
> any asserts for those just in case?
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 Hoffmann
This introduces a callback after the time that the timer is disabled and before
the MemoryMap is finalized.
This callback is useful to make final changes to the memory map due to protocols
initiated (or not initiated) by the OS loader.
Cc: Gerd Hoffmann
Cc: "Min M. Xu"
Cc: James Bottomley
Cc:
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 add a new protocol, ExitBootServicesCallbackProtocol, with a single
int
The protocol's intent is to allow drivers to install callbacks that can
modify the memory map at ExitBootServices time, so that any changes will
lead to the EFI_INVALID_PARAMETER error. This error is specified to require
the EBS caller to call GetMemoryMap again if it already had.
Cc: Gerd Hoffman
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 protocol is not disabled. This allows safe
upgrades for OS loaders to
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 st
This protocol implementation disables the accept-all-memory behavior
of the ExitBootServicesCallback instance thise 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:
Instead of eagerly accepting all memory in PEI, only accept memory under
the 4GB address. This allows a loaded image to use the
ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL to disable the accept behavior and
indicate that it can interpret the memory type accordingly.
This classification is safe since Exi
>
> Is it defined by UEFI Spec?
>
It is not. This is Ard's suggested solution
https://patchew.org/EDK2/20220928153323.2583389-1-dionnagl...@google.com/20220928153323.2583389-5-dionnagl...@google.com/#camj1kxfwbu9oiulufxsrqhag1pf+yu2dl4jbuz2lo0k9uue...@mail.gmail.com
--
-Dionna Glaze, PhD (she/he
CreateEvent returns an EFI_STATUS. It expects the OUT parameter, a
pointer to an EFI_EVENT, to be non-NULL. A null pointer results in
EFI_INVALID_PARAMETER. If the CreateEvent is successful, then `event`
points to the newly created event. It's the caller's responsibility to
pass a pointer to valid
>
> What Ray is getting to (I think) is that that means that it should be
> defined in MdeModulePkg not MdePkg.
Oh, MemoryAcceptProtocol is also not specified AFAICT, so I thought
this is where it would go. I can move it.
--
-Dionna Glaze, PhD (she/her)
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links:
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 add a new protocol, ExitBootServicesCallbackProtocol, with a single
int
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 Hoffmann
This introduces a callback after the time that the timer is disabled and before
the MemoryMap is finalized.
This callback is useful to make final changes to the memory map due to protocols
initiated (or not initiated) by the OS loader.
Cc: Gerd Hoffmann
Cc: "Min M. Xu"
Cc: James Bottomley
Cc:
The protocol's intent is to allow drivers to install callbacks that can
modify the memory map at ExitBootServices time, so that any changes will
lead to the EFI_INVALID_PARAMETER error. This error is specified to require
the EBS caller to call GetMemoryMap again if it already had.
Cc: Gerd Hoffman
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 protocol is not disabled. This allows safe
upgrades for OS loaders to
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 st
This protocol implementation disables the accept-all-memory behavior
of the ExitBootServicesCallback instance thise 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:
Instead of eagerly accepting all memory in PEI, only accept memory under
the 4GB address. This allows a loaded image to use the
ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL to disable the accept behavior and
indicate that it can interpret the memory type accordingly.
This classification is safe since Exi
Thanks Felix, this is great! I'll change the implementation to just be
this specified thing.
On Wed, Oct 5, 2022 at 9:20 AM Felix Polyudov wrote:
>
> > On Mon, 3 Oct 2022 at 03:16, Dionna Amalie Glaze
> > wrote:
> > >
> > > >
> > > > Is it defined by UEFI Spec?
> > > >
> > >
> > > It is not. Thi
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,
EFI_EVENT_GROUP_BE
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 Hoffmann
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 -
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
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 st
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: Dionna
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 to
Instead of eagerly accepting all memory in PEI, only accept memory under
the 4GB address. This allows a loaded image to use the
ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL to disable the accept behavior and
indicate that it can interpret the memory type accordingly.
This classification is safe since Exi
The specification says that disabling the timer should happen right
after. Ard told me it should still work this way.
On Wed, Oct 5, 2022 at 1:50 PM Tom Lendacky wrote:
>
> On 10/5/22 15:33, Dionna Glaze wrote:
> > Location of notification is has been specified in UEFI v2.9.
> >
> > Cc: Gerd Hoff
> Ard told me it should still work this way.
>
Let me clarify that I've also tested the new code and it does still work.
--
-Dionna Glaze, PhD (she/her)
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94774): https://edk2.groups.io/g/d
>
> Can OS call AcceptMemory protocol for those ranges that are not accepted?
>
AcceptMemory is not specified to avoid accepting previously accepted
memory. As I understand it, AcceptMemory is purely a hardware
abstraction layer for CC technologies inside the UEFI implementation.
It additionally i
> 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 on
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 se
>
> 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 then
> 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 spec
> > 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 variabl
> > 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 c
>
> 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 (missing
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,
EFI_EVENT_GROUP_BE
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 Hoffmann
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 -
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 to
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 st
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: Dionna
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 ExitBootServic
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
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
>
> 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)
-=-=-=-=-=-=-=-=-=-=-=-
Groups.
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 EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SER
>
> 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 t
1 - 100 of 168 matches
Mail list logo
