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

["Aithal, Srikanth via groups.io" <srikanth.aithal=amd.com@groups.io>]

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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-