Kernel Loader Hashes disabled for SEV-SNP

[hstr0]

Hi there,

we are currently working with SEV-SNP to include initrd in attestation report. However, the function sev_add_kernel_loader_hashes() in /qemu/target/i386/sev.c returns false when SEV-SNP is enabled:

if (sev_snp_enabled()) {
  return false;
}

What are the next steps to add support for this kind of attestation? Any help is appreciated.

[tlendacky]

The Qemu patches are an RFC set of patches and enough to boot an SNP guest. Once the hypervisor support is close to being finalized is when the Qemu patches will be more formal. At that point, I would recommend you keep an eye on that mailing list and bring up questions/comments related to this type of support at that time. You could even bring it up now on the mailing list now based on the RFC patches submitted.

[hstr0]

Thank you for the reply! Since we don't have time to wait for an indefinite point in the future, we are going to bring it up now on the corresponding mailing list.

If someone had the same issue and solved it for their own project, we are grateful for any hint.

[dubek]

Hi @hstr0 ,
In March 2022 I submitted RFC patches to enable kernel loader hashes for SEV-SNP:

edk2 patches: [PATCH 0/2] OvmfPkg: Enable measured direct boot on AMD SEV-SNP

QEMU patch: [RFC PATCH] i386/sev: Support measured direct -kernel boot on SNP -- note the it's based on top of the RFC QEMU snp-v3 tree from AMD.

Hope this helps.

[hstr0]

Hi @dubek,

thanks a lot! We already patched our system and still need to verify the effectiveness of the changes made.

[Daviiap]

Hi @dubek,

thanks a lot! We already patched our system and still need to verify the effectiveness of the changes made.

Hey @hstr0, were you able to generate the measurement with the kernel and the initrd? I'm trying to do this, but no success...

[hstr0]

Hi @dubek,
thanks a lot! We already patched our system and still need to verify the effectiveness of the changes made.

Hey @hstr0, were you able to generate the measurement with the kernel and the initrd? I'm trying to do this, but no success...

Hey @Daviiap,
sorry for the late reply. We patched the OVMF and QEMU as indicated previously and eventually hash of kernel + kernel command line + initrd are successfully included in the measurement. The SEV-Tool provides a reference to verify.

[Daviiap]

I've patched OVMF and QEMU also and worked for me, thanks!

[hstr0]

I've patched OVMF and QEMU also and worked for me, thanks!

Glad it worked for you too!

[dubek]

BTW, on 2023-03-02 I submitted new a version (v3) of the ovmf and qemu patches; the qemu patches are now based on top of a newer RFC tree from AMD (which still works even with older SNP host kernels).

edk2/ovmf: patch series, git tree

qemu: RFC patch series, git tree

Hope this helps. Let me know here (or in the relevant mailing lists) if there are any issues.

[Anderson-Melo]

Hi @dubek, I've patched QEMU and OVMF, and I'm facing a problem.

Here the command I used to boot up the VM:

/home/monitoring/AMDSEV/usr/local/bin/qemu-system-x86_64 -enable-kvm -cpu EPYC-v4 -machine q35 -smp 4,maxcpus=64 -m 2048M,slots=5,maxmem=30G -no-reboot -drive if=pflash,format=raw,unit=0,file=/home/monitoring/AMDSEV/usr/local/share/qemu/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=/home/monitoring/AMDSEV/ubuntu20.04-cloudimg-0.fd -netdev bridge,id=net0,br=br0 -device virtio-net-pci,mac=A6:57:74:58:2E:1D,netdev=net0 -drive file=/home/monitoring/AMDSEV/ubuntu20.04-cloudimg-0.qcow2,if=none,id=disk0,format=qcow2 -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true -device scsi-hd,drive=disk0 -machine memory-encryption=sev0,vmport=off -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,kernel-hashes=on -kernel ../vmlinuz-5.19.0-rc6-snp-guest-cd1599797a25 -append "console=ttyS0 earlyprintk=serial root=/dev/sda3" -initrd ../initrd.img-5.19.0-rc6-snp-guest-cd1599797a25 -nographic -monitor pty -monitor unix:monitor,server,nowait

and the problem I'm facing:

FSOpen: Open '\EFI\BOOT\BOOTX64.EFI' Success
[Bds] Expand \EFI\BOOT\BOOTX64.EFI -> PciRoot(0x0)/Pci(0x3,0x0)/Scsi(0x0,0x0)/HD(2,GPT,ED1F2101-565F-4244-94A7-1E308AC4AAF3,0x2800,0x35000)/\EFI\BOOT\BOOTX64.EFI
[Security] 3rd party image[0] can be loaded after EndOfDxe: PciRoot(0x0)/Pci(0x3,0x0)/Scsi(0x0,0x0)/HD(2,GPT,ED1F2101-565F-4244-94A7-1E308AC4AAF3,0x2800,0x35000)/\EFI\BOOT\BOOTX64.EFI.
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7DA4B1C0
Loading driver at 0x0007C385000 EntryPoint=0x0007C3A7000 
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7DA16998
ProtectUefiImageCommon - 0x7DA4B1C0
  - 0x000000007C385000 - 0x00000000000D4000
InstallProtocolInterface: 605DAB50-E046-4300-ABB6-3DD810DD8B23 7C434220
FSOpen: Open '\EFI\BOOT\fbx64.efi' Success
FSOpen: Open '\EFI\BOOT\fbx64.efi' Success
FSOpen: Open 'EFI' Success
FSOpen: Open 'ubuntu' Success
FSOpen: Open 'BOOTX64.CSV' Success
FSOpen: Open '\EFI\ubuntu\BOOTX64.CSV' Success
FSOpen: Open '\EFI\ubuntu\shimx64.efi' Success
[Security] 3rd party image[0] can be loaded after EndOfDxe: PciRoot(0x0)/Pci(0x3,0x0)/Scsi(0x0,0x0)/HD(2,GPT,ED1F2101-565F-4244-94A7-1E308AC4AAF3,0x2800,0x35000)/\EFI\ubuntu\shimx64.efi.
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7C50D040
Loading driver at 0x0007C1C7000 EntryPoint=0x0007C1E9000 
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7C50DE98
ProtectUefiImageCommon - 0x7C50D040
  - 0x000000007C1C7000 - 0x00000000000D4000
[Variable]: Rewritten a preexisting variable(0x00000006) with different attributes(0x00000007) - 605DAB50-E046-4300-ABB6-3DD810DD8B23:MokListRT
[Variable]: Rewritten a preexisting variable(0x00000006) with different attributes(0x00000007) - 605DAB50-E046-4300-ABB6-3DD810DD8B23:MokListXRT
[Variable]: Rewritten a preexisting variable(0x00000006) with different attributes(0x00000007) - 605DAB50-E046-4300-ABB6-3DD810DD8B23:SbatLevelRT
InstallProtocolInterface: 605DAB50-E046-4300-ABB6-3DD810DD8B23 7C276220
FSOpen: Open '\EFI\ubuntu\grubx64.efi' Success
PixelBlueGreenRedReserved8BitPerColor
/tmp/cmdline.3346338: line 1: 3346382 Bus error               (core dumped) /home/monitoring/AMDSEV/usr/local/bin/qemu-system-x86_64 -enable-kvm -cpu EPYC-v4 -machine q35 -smp 4,maxcpus=64 -m 2048M,slots=5,maxmem=30G -no-reboot -drive if=pflash,format=raw,unit=0,file=/home/monitoring/AMDSEV/usr/local/share/qemu/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=/home/monitoring/AMDSEV/ubuntu20.04-cloudimg-0.fd -netdev bridge,id=net0,br=br0 -device virtio-net-pci,mac=DA:DF:DE:B3:2F:6D,netdev=net0 -drive file=/home/monitoring/AMDSEV/ubuntu20.04-cloudimg-0.qcow2,if=none,id=disk0,format=qcow2 -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true -device scsi-hd,drive=disk0 -machine memory-encryption=sev0,vmport=off -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,kernel-hashes=on -kernel ../vmlinuz-5.19.0-rc6-snp-guest-cd1599797a25 -append "console=ttyS0 earlyprintk=serial root=/dev/sda3" -initrd ../initrd.img-5.19.0-rc6-snp-guest-cd1599797a25 -nographic -monitor pty -monitor unix:monitor,server,nowait

Do you have any idea what could be causing this problem?

[dubek]

@Anderson-Melo I'm not sure. Here are a few questions to attempt debug this:

1. Which package/target of OVMF did you build? For kernel-hashes support, you must build edk2 with: -p OvmfPkg/AmdSev/AmdSevX64.dsc (instead of the regular OVMF build which has -p OvmfPkg/OvmfPkgX64.dsc.

2. Before running that OVMF build you'll need to run touch OvmfPkg/AmdSev/Grub/grub.efi.

3. The OVMF build should produce one image: Build/AmdSev/DEBUG_GCC5/FV/OVMF.fd (and not separate OVMF_CODE / OVMF_VARS images).

4. Remove the second pflash image (unit=1).

5. Look for OVMF logs which refer to the kernel hashes verification; for example:

   BlobVerifierLibSevHashesConstructor: Found injected hashes table in secure location    
   Select Item: 0x17
   Select Item: 0x8
   FetchBlob: loading 8304128 bytes for "kernel"
   Select Item: 0x18
   Select Item: 0x11
   VerifyBlob: Found GUID 4DE79437-ABD2-427F-B835-D5B172D2045B in table
   VerifyBlob: Hash comparison succeeded for "kernel"
   Select Item: 0xB
   FetchBlob: loading 105807810 bytes for "initrd"
   Select Item: 0x12
   VerifyBlob: Found GUID 44BAF731-3A2F-4BD7-9AF1-41E29169781D in table
   VerifyBlob: Hash comparison succeeded for "initrd"
   Select Item: 0x14
   FetchBlob: loading 83 bytes for "cmdline"
   Select Item: 0x15
   VerifyBlob: Found GUID 97D02DD8-BD20-4C94-AA78-E7714D36AB2A in table
   VerifyBlob: Hash comparison succeeded for "cmdline"
   

6. QEMU 7.2 has a bug where it modifies the kernel image (or cmdline) and ruins the kernel hashes verification. You can circumvent it by adding -machine pc-q35-7.1 to the QEMU cmdline. It is solved in 8.0 which should be released soon.

Maybe one of these can shed more light on the issue.

[Anderson-Melo]

@dubek Thanks, this -machine pc-q35-7.1 and a unique image of OVMF solved my initial problem, but the issue persists when attempting to set kernel-hashes=off.