In order to allow the VMM (such as QEMU) to add a page with hashes of kernel/initrd/cmdline for measured direct boot on SNP, add it explicitly to the SNP metadata list report to the VMM. In such case,

Resize the MEMFD section of AmdSevX64.fdf and reorder its pages so that it matches the same size and order used in OvmfPkgX64.fdf. After this change, this is the difference in the MEMFD of the two tar

AMD SEV and SEV-ES support measured direct boot with kernel/initrd/cmdline hashes injected by QEMU and verified by OVMF during boot. To enable the same approach for AMD SEV-SNP, we declare the kernel

Or maybe this metadata section ^^^^^ should be added only if the Pcd for secrets+hashes page is defined? -Dov

Thanks for the feedback Tom and Gerd. I can define a new section type OVMF_SECTION_TYPE_KERNEL_HASHES. In the AmdSev target it'll cover the single MEMFD page at 00F000 (after the CPUID page). Now ther

In order to allow the VMM (such as QEMU) to add a page with hashes of kernel/initrd/cmdline for measured direct boot on SNP, this page must not be part of the SNP metadata list reported to the VMM. Ch

Resize the MEMFD section of AmdSevX64.fdf and reorder its pages so that it matches the same size and order used in OvmfPkgX64.fdf. After this change, this is the difference in the MEMFD of the two tar

[Resending due to missing Cc in actual patches emails.] (Note: This is a new version of this one-year-old patch series; the v1 series [1] got a few Acked-by but it's been so long that I don't consider

The corresponding QEMU RFC patch series is at: https://lore.kernel.org/qemu-devel/20230216084913.2148508-1-dovmurik@... and the QEMU tree can be fetched from: https://github.com/confidentia

In order to allow the VMM (such as QEMU) to add a page with hashes of kernel/initrd/cmdline for measured direct boot on SNP, this page must not be part of the SNP metadata list reported to the VMM. Ch

(Note: This is a new version of this one-year-old patch series; the v1 series [1] got a few Acked-by but it's been so long that I don't consider them relevant anymore.) AMD SEV and SEV-ES support meas

Resize the MEMFD section of AmdSevX64.fdf and reorder its pages so that it matches the same size and order used in OvmfPkgX64.fdf. After this change, this is the difference in the MEMFD of the two tar

Hi Jiewen, EfiACPIReclaimMemory type was suggested by Ard [1] for a similar fix another SEV-related memory area that should remain in-place throughout the guest OS lifetime (not reused by OS). Ard --

Thanks Mike for fixing this. Reviewed-by: Dov Murik <dovmurik@...>

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3D4186 Commit 079a58276b98 ("OvmfPkg/AmdSev/SecretPei: Mark SEV launch secret area as reserved") marked the launch secret area itself (1 page) as res

Thank you Jiewen. I haven't -- last time I contributed to edk2 was a long time ago; I'll look for the instructions on triggering the CI myself. I see patch format errors (lines a bit too long) and unc

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3D4186 Commit 079a58276b98 ("OvmfPkg/AmdSev/SecretPei: Mark SEV launch secret area as reserved") marked the launch secret area itself (1 page) as res

Thanks Ard for reviewing this patch. Just making sure -- this data might be useful in grub (if we embed grub into OVMF to boot encrypted disk from an SEV injected launch secret) and/or in Linux (modul

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3D4186 Commit 079a58276b98 ("OvmfPkg/AmdSev/SecretPei: Mark SEV launch secret area as reserved") marked the launch secret area itself (1 page) as res

Gerd, thanks for the cleanup. Tested-by: Dov Murik <dovmurik@...> Reviewed-by: Dov Murik <dovmurik@...>