In QemuKernelLoaderFsDxeEntrypoint we use FetchBlob to read the content of the kernel/initrd/cmdline from the QEMU fw_cfg interface. Insert a call to VerifyBlob after fetching to allow BlobVerifierLib

This prepares the ground for calling VerifyBlob() in QemuKernelLoaderFsDxe. Cc: Ard Biesheuvel <ardb+tianocore@...> Cc: Jordan Justen <jordan.l.justen@...> Cc: Ashish Kalra <ashish.kalra@

In the AmdSevX64 build, use BlobVerifierLibSevHashes to enforce verification of hashes of the kernel/initrd/cmdline blobs fetched from firmware config. This allows for secure (measured) boot of SEV gu

Add an implementation for BlobVerifierLib that locates the SEV hashes table and verifies that the calculated hashes of the kernel, initrd, and cmdline blobs indeed match the expected hashes stated in

From: James Bottomley <jejb@...> Split the existing 4KB page reserved for SEV launch secrets into two parts: first 3KB for SEV launch secrets and last 1KB for firmware config hashes. The are

This prepares the ground for calling VerifyBlob() in QemuKernelLoaderFsDxe. Cc: Ard Biesheuvel <ardb+tianocore@...> Cc: Leif Lindholm <leif@...> Cc: Sami Mujawar <sami.mujawar@...>

BlobVerifierLib will be used to verify blobs fetching them from QEMU's firmware config (fw_cfg) in platforms that enable such verification. The null implementation BlobVerifierLibNull treats all blobs

From: James Bottomley <jejb@...> Commit 96201ae7bf97 ("OvmfPkg/AmdSev/SecretDxe: make secret location naming generic", 2020-12-15) replaced references to SEV with the generic term Confidenti

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3457 Booting with SEV prevented the loading of kernel, initrd, and kernel command-line via QEMU fw_cfg interface because they arrive from the VMM whi

With this patch we'll have two identical files: OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c OvmfPkg/Library/PlatformBootManagerLibGrub/QemuKernel.c but there's another QemuKernel.c, which is *

I think so. Be sure to include full logs as much as possible and details about the image you're trying to start; it seems to me that if the kernel starts and initrd is mounted etc then both QEMU and O

Adding Tom too - I think he modified the OVMF reset vector lately and might know. I'm not an expert, but I think that OVMF has its own reset vector in OvmfPkg/ResetVector, and therefore the changes in

You're right -- it can be extended. Currently that's not the plan; the Guest Owner should be able to verify the measurement, which, with this patch series, is a combination of the OVMF, kernel, initrd

Indeed. But is this BASE_NAME okay? Or should it be BlobVerifierLibSevHashes ? Detect overflows in the `for` loop below? If a (bad) Entry->Len is 0xffff, then adding it to Len will overflow the UINT16

Yes, that's much better. Thanks for introducing me to this macro. -Dov

It's a sad winking face... I'll fix. Thanks, -Dov

Thanks, I'll change that. You're right; I'll rename. Probably not; I'll remove. OK. You're right. I'll add it. Thanks, -Dov

You're right; I'll write it clearer. I guess it's possible by extracting the file into its own library? I'll need to take a deeper look. -Dov

Oh I missed a few. I'll fix. Thanks.

Can you please try with edk2 commit d1fc3d7ef3cb - just before we did some changes around this QEMU-interop code in OVMF? Thanks, Dov