Re: [PATCH v6] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Mar 21, 2025 at 09:22:59AM +0100, Gerd Hoffman wrote:
> On Thu, Mar 20, 2025 at 09:34:26AM +0100, Jörg Rödel wrote:
> > On Tue, Mar 18, 2025 at 12:11:02PM +0100, Gerd Hoffman wrote:
> > > Open questions:
> > > 
> > >  - Does the idea to use igvm parameters for the kernel hashes makes
> > >    sense?  Are parameters part of the launch measurement?
> > 
> > Parameters itself are fully measured, their presence is, but not their
> > data. This is to keep the same launch measurements across different
> > platform configurations.
> > 
> > So for hashes it is best to put some on some measured page and let the
> > parameters point to it.
> 
> Had a look at the kernel hashes details this week.
> 
> So, the story is this: It's essentially a private arrangement between
> ovmf (the amdsev build variant only) and qemu.  The hashes are placed in
> a specific page, together with "launch secrets" (that is not the sev-snp
> "secrets" page).  That page is part of the lanuch measurement.  That
> effectively makes the kernel + initrd + cmdline part of the launch
> measurement too (ovmf verifies the hashes), but without the relatively
> slow secure processor hashing kernel + initrd + cmdline, which reduces
> the time needed to launch a VM.
> 
> The "launch secret" is intended to hold things like a luks secret to
> unlock the root filesystem.  OVMF doesn't touch it but reserves the page
> and registers a EFI table for it so the linux kernel can find it.
> 
> As far I know these are more experimental bits than something actually
> used in production.  It's also clearly a pre-UKI design.  That IMHO
> opens up the question whenever we actually want carry forward with that,
> or if we better check out what alternatives we have.  We'll have a
> signed UKI after all, so going for secure boot and/or measured boot for
> the UKI verification looks attractive compared to passing around hashes
> for the elements inside the UKI.

Although it has been extended to SNP in QEMU, personally I'd consider
the QEMU 'kernel hashes' functionality to be an niche feature.

From a virt mgmt POV we know in general that direct kernel boot while
useful, is somewhat limited in usage. Most of the time it is saner to
have the guest decide what kernel to boot without interaction of the
host. So by extension, the kernel hashes feature is also going to be
a similarly (or even more) niche use case. The UKI with system extensions
and secureboot model gives much greater flexibility for defining policy
around valid configurations than using fixed hashes - especially when
it comes to kernel command line which has potentially many valid configs.


> Not fully sure what to do about the "launch secrets".  IIRC the initial
> design of this is for sev-es, i.e. pre-snp, so maybe the sev-snp secrets
> page can be used instead.  I see the spec has 0x60 bytes (offset 0xa0)
> reserved for guest os usage.  In any case this probably is only needed
> as temporary stopgap until we have a complete vTPM implementation for
> the svsm.

I view the launch secrets feature as a crutch to cope with the HW
limitations of SEV/SEV-ES. You have the host initiated attestation
dance and after verification can pass data back to the host, which
will inject it into the guest. The inability to have a secure TPM
in SEV/SEV-ES forces you down this road. It is highly undesirable
as a feature going forward because we're better served by having
a boot workflow that is common to traditional virt, confidential
virt, and bare metal, and TPM delivers on that.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|