The current #VC handler guards against MMIO to addresses that are mapped
with the encryption bit set, but has an special exception for MMIO
accesses to the APIC base address so allow for early access during SEC.
Now that the SEC page table has the encryption bit cleared for the APIC
base address
For the most part, OVMF will clear the encryption bit for MMIO regions,
but there is currently one known exception during SEC when the APIC
base address is accessed via MMIO with the encryption bit set for
SEV-ES/SEV-SNP guests. In the case of SEV-SNP, this requires special
handling on the
Future changes will make use of CpuPageTableLib to handle splitting
page table mappings during SEC phase. While it's not strictly required
by hardware, CpuPageTableLib relies on non-leaf PTEs never having the
encryption bit set, so go ahead change the page table setup code to
satisfy this
For the most part, OVMF will clear the encryption bit for MMIO regions,
but there is currently one known exception during SEC when the APIC
base address is accessed via MMIO with the encryption bit set for
SEV-ES/SEV-SNP guests. In the case of SEV-SNP, this requires special
handling on the
On Fri, Apr 26, 2024 at 05:25:15PM +0200, Ard Biesheuvel wrote:
> On Fri, 26 Apr 2024 at 16:16, Roth, Michael via groups.io
> wrote:
> >
> > On Fri, Apr 26, 2024 at 08:51:20AM -0500, Roth, Michael via groups.io wrote:
> > > For the most part, OVMF will clear the encr
For the most part, OVMF will clear the encryption bit for MMIO regions,
but there is currently one known exception during SEC when the APIC
base address is accessed via MMIO with the encryption bit set for
SEV-ES/SEV-SNP guests. In the case of SEV-SNP, this requires special
handling on the
On Fri, Apr 26, 2024 at 08:51:20AM -0500, Roth, Michael via groups.io wrote:
> For the most part, OVMF will clear the encryption bit for MMIO regions,
> but there is currently one known exception during SEC when the APIC
> base address is accessed via MMIO with the encryption bit set for
For the most part, OVMF will clear the encryption bit for MMIO regions,
but there is currently one known exception during SEC when the APIC
base address is accessed via MMIO with the encryption bit set for
SEV-ES/SEV-SNP guests. In the case of SEV-SNP, this requires special
handling on the
On Wed, Apr 24, 2024 at 01:54:01PM +0200, Gerd Hoffmann wrote:
> On Tue, Apr 23, 2024 at 03:59:58PM -0500, Michael Roth wrote:
> > For the most part, OVMF will clear the encryption bit for MMIO regions,
> > but there is currently one known exception during SEC when the APIC
> > base address is
For the most part, OVMF will clear the encryption bit for MMIO regions,
but there is currently one known exception during SEC when the APIC
base address is accessed via MMIO with the encryption bit set for
SEV-ES/SEV-SNP guests. In the case of SEV-SNP, this requires special
handling on the
The struct used for GHCB-based page-state change requests uses a 40-bit
bit-field for the GFN, which is shifted by PAGE_SHIFT to generate a
64-bit address. However, anything beyond 40-bits simply gets shifted off
when doing this, which will cause issues when dealing with 1TB+
addresses. Fix this
Quoting Gerd Hoffmann (2023-11-13 04:48:10)
> On Fri, Nov 10, 2023 at 08:14:39PM -0600, Michael Roth wrote:
> > The struct used for GHCB-based page-state change requests uses a 40-bit
> > bit-field for the GFN, which is shifted by PAGE_SHIFT to generate a
> > 64-bit address. However, anything
The struct used for GHCB-based page-state change requests uses a 40-bit
bit-field for the GFN, which is shifted by PAGE_SHIFT to generate a
64-bit address. However, anything beyond 40-bits simply gets shifted off
when doing this, which will cause issues when dealing with 1TB+
addresses. Fix this
PcdFirstTimeWakeUpAPsBySipi was recently introduced to indicate when
the full INIT-SIPI-SIPI sequence can be skipped for AP bringup. It is
true by default, but needs to be disabled for QEMU/OVMF where early INIT
is not simulated. Commit 1d76560146 ("OvmfPkg: Disable
PcdFirstTimeWakeUpAPsBySipi.")
Booting an SEV guest with AmdSev OVMF package currently triggers the
following assertion with QEMU:
InstallQemuFwCfgTables: installed 7 tables
PcRtc: Write 0x20 to CMOS location 0x32
[Variable]END_OF_DXE is signaled
Initialize variable error flag (FF)
ASSERT_EFI_ERROR (Status = Not
A couple changes broke booting of SEV and SNP guests when using the
AmdSevX64 package in conjunction with QEMU:
UefiCpuPkg:Wake up APs after power-up or RESET through SIPI.
OvmfPkg/AmdSev: stop using PlatformBootManagerLibGrub
Both fixes are fairly straightforward and mainly seem to stem
Currently OVMF tries to rely on the base size advertised via the CPUID
table entries corresponding to leaf 0xD, sub-leafs 0x0/0x1. This will
generally work for KVM guests, but might not for other SEV-SNP
hypervisor implementations. Make the handling more robust by simply
using the base area size
CPUID leaf 0xD sub-leafs 0x0 and 0x1 contain cumulative sizes for the
enabled XSave areas. Those sizes are calculated by tallying up all the
other sub-leafs that contain per-area size information for XSave areas
that are currently enabled in XCr0/XSS. The current check has the logic
inverted. Fix
The Confidential Computing blob defined here is intended to match the
definition defined by linux guest kernel. Previously, both definitions
relied on natural alignment, but that relies on both OVMF and kernel
being compiled as 64-bit. While there aren't currently any plans to
enable SNP support
The SEV-SNP Confidential Computing blob contains metadata that should
remain accessible for the life of the guest. Allocate it as
EfiACPIReclaimMemory to ensure the memory isn't overwritten by the guest
operating system later.
Reported-by: Dov Murik
Suggested-by: Dov Murik
Reviewed-by: Dov
(Mainly a resend of v1, but rolled in Gerd's Acked-by's, addressed
new coding style check in the CI, and updated Cc list)
Here are a number of fixes related to OVMF handling of the SEV-SNP
Confidential Computing blob and CPUID table.
Patch #1 is a fix for recently-reported issue that can cause
On Wed, Mar 15, 2023 at 04:57:43PM -0500, Michael Roth wrote:
> (Rebased series and resending due to merge conflict with previous
> submission.)
Ping.
>
> Here are a number of fixes related to OVMF handling of the SEV-SNP
> Confidential Computing blob and CPUID table.
>
> Patch #1 is a fix for
Currently OVMF tries to rely on the base size advertised via the CPUID
table entries corresponding to leaf 0xD, sub-leafs 0x0/0x1. This will
generally work for KVM guests, but might not for other SEV-SNP
hypervisor implementations. Make the handling more robust by simply
using the base area size
CPUID leaf 0xD sub-leafs 0x0 and 0x1 contain cumulative sizes for the
enabled XSave areas. Those sizes are calculated by tallying up all the
other sub-leafs that contain per-area size information for XSave areas
that are currently enabled in XCr0/XSS. The current check has the logic
inverted. Fix
The Confidential Computing blob defined here is intended to match the
definition defined by linux guest kernel. Previously, both definitions
relied on natural alignment, but that relies on both OVMF and kernel
being compiled as 64-bit. While there aren't currently any plans to
enable SNP support
The SEV-SNP Confidential Computing blob contains metadata that should
remain accessible for the life of the guest. Allocate it as
EfiACPIReclaimMemory to ensure the memory isn't overwritten by the guest
operating system later.
Reported-by: Dov Murik
Suggested-by: Dov Murik
Reviewed-by: Dov
(Rebased series and resending due to merge conflict with previous
submission.)
Here are a number of fixes related to OVMF handling of the SEV-SNP
Confidential Computing blob and CPUID table.
Patch #1 is a fix for recently-reported issue that can cause
significant problems with some SEV-SNP guest
On Wed, Dec 21, 2022 at 10:06:47AM -0600, Michael Roth wrote:
> Here are a number of fixes related to OVMF handling of the SEV-SNP
> Confidential Computing blob and CPUID table.
>
> Patch #1 is a fix for recently-reported issue that can cause
> significant problems with some SEV-SNP guest
CPUID leaf 0xD sub-leafs 0x0 and 0x1 contain cumulative sizes for the
enabled XSave areas. Those sizes are calculated by tallying up all the
other sub-leafs that contain per-area size information for XSave areas
that are currently enabled in XCr0/XSS. The current check has the logic
inverted. Fix
On Wed, Dec 21, 2022 at 09:50:43AM -0600, Michael Roth wrote:
> A full-featured SEV-SNP guest will not rely on the AP jump table, and
> will instead use the AP Creation interface defined by the GHCB. However,
> a guest is still allowed to use the AP jump table if desired.
>
> However, unlike with
The SEV-SNP Confidential Computing blob contains metadata that should
remain accessible for the life of the guest. Allocate it as
EfiACPIReclaimMemory to ensure the memory isn't overwritten by the guest
operating system later.
Reported-by: Dov Murik
Suggested-by: Dov Murik
Signed-off-by:
Currently OVMF tries to rely on the base size advertised via the CPUID
table entries corresponding to leaf 0xD, sub-leafs 0x0/0x1. This will
generally work for KVM guests, but might not for other SEV-SNP
hypervisor implementations. Make the handling more robust by simply
using the base area size
OvmfPkg will initially use this to hand off the secrets page address to
UefiCpuPkg, which will need this PCD to access the SEV-SNP secrets page
address. Define this as an MdePkg PCD so it can be accessed by other
packages alongside the secrets page struct defined in MdePkg/Include.
Reviewed-by:
This will be needed so that the AP Jump Table address can be stored for
use by the operating system later, and possibly for other things in the
future.
Reviewed-by: Tom Lendacky
Signed-off-by: Michael Roth
---
MdePkg/Include/Register/Amd/SnpSecretsPage.h | 56
1 file
The Confidential Computing blob defined here is intended to match the
definition defined by linux guest kernel. Previously, both definitions
relied on natural alignment, but that relies on both OVMF and kernel
being compiled as 64-bit. While there aren't currently any plans to
enable SNP support
Add myself as a reviewer for OVMF/Confidential Computing patches.
Remove Brijesh while at it, since he is no longer at AMD, and the email
is no longer valid.
Suggested-by: Tom Lendacky
Signed-off-by: Michael Roth
---
Maintainers.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
A full-featured SEV-SNP guest will not rely on the AP jump table, and
will instead use the AP Creation interface defined by the GHCB. However,
a guest is still allowed to use the AP jump table if desired.
However, unlike with SEV-ES guests, SEV-SNP guests should not
store/retrieve the jump table
This needs to be set so that UefiCpuPkg can locate the SEV-SNP secrets
page later to set the AP Jump Table address.
Reviewed-by: Tom Lendacky
Signed-off-by: Michael Roth
---
OvmfPkg/AmdSev/AmdSevX64.dsc| 3 +++
OvmfPkg/CloudHv/CloudHvX64.dsc | 3 +++
Here are a number of fixes related to OVMF handling of the SEV-SNP
Confidential Computing blob and CPUID table.
Patch #1 is a fix for recently-reported issue that can cause
significant problems with some SEV-SNP guest operating systems.
Please consider applying this patch directly if the other
A full-featured SEV-SNP guest will not rely on the AP jump table, and
will instead use the AP Creation interface defined by the GHCB. However,
a guest is still allowed to use the AP jump table if desired.
However, unlike with SEV-ES guests, SEV-SNP guests should not
store/retrieve the jump table
40 matches
Mail list logo
