qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/3] sev/i386: Allow launching with -kernel if no OVMF hashes


From: Tom Lendacky
Subject: Re: [PATCH 1/3] sev/i386: Allow launching with -kernel if no OVMF hashes table found
Date: Mon, 1 Nov 2021 09:25:25 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 11/1/21 5:21 AM, Dov Murik wrote:
Commit cff03145ed3c ("sev/i386: Introduce sev_add_kernel_loader_hashes
for measured linux boot", 2021-09-30) introduced measured direct boot
with -kernel, using an OVMF-designated hashes table which QEMU fills.

However, if OVMF doesn't designate such an area, QEMU would completely
abort the VM launch.  This breaks launching with -kernel using older
OVMF images which don't publish the SEV_HASH_TABLE_RV_GUID.

Instead, just warn the user that -kernel was supplied by OVMF doesn't
specify the GUID for the hashes table.  The following warning will be
displayed during VM launch:

     qemu-system-x86_64: warning: SEV: kernel specified but OVMF has no hash 
table guid

Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Reported-by: Tom Lendacky <thomas.lendacky@amd.com>

Just a few minor comments/questions below, otherwise:

Acked-by: Tom Lendacky <thomas.lendacky@amd.com>

---
  target/i386/sev.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/i386/sev.c b/target/i386/sev.c
index eede07f11d..682b8ccf6c 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -1204,7 +1204,7 @@ bool sev_add_kernel_loader_hashes(SevKernelLoaderContext 
*ctx, Error **errp)
      int aligned_len;
if (!pc_system_ovmf_table_find(SEV_HASH_TABLE_RV_GUID, &data, NULL)) {
-        error_setg(errp, "SEV: kernel specified but OVMF has no hash table 
guid");
+        warn_report("SEV: kernel specified but OVMF has no hash table guid");

Not sure if warn or info would be better, either way works for me, though, since this allows the guest to boot now.

Unrelated to this change, but do we explicitly want to say OVMF? Can't another BIOS/UEFI implementation have this support?

and should guid be GUID?

Thanks,
Tom

          return false;
      }
      area = (SevHashTableDescriptor *)data;




reply via email to

[Prev in Thread] Current Thread [Next in Thread]