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

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

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
> 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 (#119720): https://edk2.groups.io/g/devel/message/119720
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]
-=-=-=-=-=-=-=-=-=-=-=-