On 6/26/2024 7:28 PM, Tobin Feldman-Fitzthum wrote:
On 6/26/24 4:08 AM, Aithal, Srikanth wrote:
Hello, SEV/SEVES guest boot fails with AMDSEV OVMF package built
using upstream edk2 master [commit head:
2fbaaa96d11ad61a9133df1728e3fe965d1457a5]. SEV/SEVES guest boot with
AMDSEV package gets stuck at below point: Plain Text 2024-06-26
04: 38: 02:
Hello,
SEV/SEVES guest boot fails with AMDSEV OVMF package built using
upstream edk2 master [commit
head: 2fbaaa96d11ad61a9133df1728e3fe965d1457a5].
SEV/SEVES guest boot with AMDSEV package gets stuck at below point:
Plain Text
|2024-06-26 04:38:02: FetchBlob: loading 14332416 bytes for "kernel"
2024-06-26 04:38:02: Select Item: 0x18 2024-06-26 04:38:02: Select
Item: 0x11 2024-06-26 04:38:02: VerifyBlob: Found GUID
4DE79437-ABD2-427F-B835-D5B172D2045B in table 2024-06-26 04:38:02:
VerifyBlob: Hash comparison succeeded for "kernel" 2024-06-26
04:38:02: Select Item: 0xB 2024-06-26 04:38:02: VerifyBlob: Found
GUID 44BAF731-3A2F-4BD7-9AF1-41E29169781D in table 2024-06-26
04:38:02: VerifyBlob: Blob Specified in Hash Table was not Provided
--> Hung here |
Can you send qemu command that produces this case?
It looks like what is happening is that the initrd is specified in the
hash table, but is not provided to the guest.
You might try with and without the -initrd option and compare.
It's possible that when -initrd is not provided, QEMU will still put
something in the table, which this patch might not account for.
-Tobin
my qemu command line to recreate the issue:
qemu-system-x86_64 \
-machine q35,confidential-guest-support=sev0,vmport=off \
-object sev-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,kernel-hashes=on \
-name guest=vm,debug-threads=on \
-drive
if=pflash,format=raw,unit=0,file=/VT_BUILD/OVMF_AmdSev/OVMF.fd,readonly \
-cpu host \
-m 4096 \
-kernel '/VT_BUILD/usr/local/bzImage' \
-append 'root=/dev/sda rw console=ttyS0,115200n8
earlyprintk=ttyS0,115200 net.ifnames=0 biosdevname=0 movable_node
swiotlb=65536' \
-smp 1,cores=1,threads=1,dies=1,sockets=1 \
-drive
file=/VT_BUILD/images/22.04-server.qcow2,index=0,media=disk,format=qcow2 \
--enable-kvm \
--nographic
Yes, if I pass -initrd explicitly the Hash verify step passes properly
FetchBlob: loading 14332416 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 75379943 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 120 bytes for "cmdline"
Select Item: 0x15
VerifyBlob: Found GUID 97D02DD8-BD20-4C94-AA78-E7714D36AB2A in table
VerifyBlob: Hash comparison succeeded for "cmdline"
This was working until yesterday [commit head: be38c01], where we can
see boot was proceeding
Plain Text
|2024-06-25 03:13:23: VerifyBlob: Found GUID
4DE79437-ABD2-427F-B835-D5B172D2045B in table 2024-06-25 03:13:23:
VerifyBlob: Hash comparison succeeded for "kernel" 2024-06-25
03:13:23: Select Item: 0xB 2024-06-25 03:13:23: VerifyBlob: Found
GUID 44BAF731-3A2F-4BD7-9AF1-41E29169781D in table 2024-06-25
03:13:23: VerifyBlob: Hash comparison succeeded for "initrd"
2024-06-25 03:13:23: Select Item: 0x14 2024-06-25 03:13:23:
FetchBlob: loading 120 bytes for "cmdline" 2024-06-25 03:13:23:
Select Item: 0x15 2024-06-25 03:13:23: VerifyBlob: Found GUID
97D02DD8-BD20-4C94-AA78-E7714D36AB2A in table 2024-06-25 03:13:23:
VerifyBlob: Hash comparison succeeded for "cmdline"|
After this patch got merged the regression is seen.
Thanks,
Srikanth Aithal
On 5/7/2024 1:57 AM, Tobin Feldman-Fitzthum via groups.io wrote:
The AmdSev package has a so-called BlobVerifier, which
is meant to extend the TCB of a confidential guest
(SEV or SNP) to include components provided via fw_cfg
such as initrd, kernel, kernel params.
This series fixes a few implementation errors in the
blob verifier. One common theme is that the verifier
currently fails to halt the boot when an invalid blob
is detected. This can lead to a confidential guest
having a launch measurement that does not reflect the
guest TCB.
This series could also help us move towards consolidating
the AmdSev package back into the OvmfPkg although more
discussion will be needed on this.
Thank you for Ryan Savino at AMD for pointing out
some of these issues.
Tobin Feldman-Fitzthum (2):
AmdSev: Rework Blob Verifier
AmdSev: Halt on failed blob allocation
.../BlobVerifierSevHashes.c | 56
++++++++++++++++---
OvmfPkg/Include/Library/BlobVerifierLib.h | 14 +++--
.../BlobVerifierLibNull/BlobVerifierNull.c | 13 +++--
.../QemuKernelLoaderFsDxe.c | 9 ++-
4 files changed, 69 insertions(+), 23 deletions(-)
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119718): https://edk2.groups.io/g/devel/message/119718
Mute This Topic: https://groups.io/mt/105977013/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
