Re: [edk2-devel] [PATCH 0/2] AmdSev: Harden SEV Kernel hashes verifier

[Tobin Feldman-Fitzthum <tobin@linux.ibm.com>]

On 6/26/24 10:33 AM, Aithal, Srikanth wrote:
> 
> 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"
> 
Ok, I'll submit a little tweak this afternoon that should fix your case.

-Tobin
>>> 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 (#119725): https://edk2.groups.io/g/devel/message/119725
Mute This Topic: https://groups.io/mt/105977013/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-