On Mon, Jan 17, 2022 at 09:34:30AM +0200, Dov Murik wrote:
> [+cc Tom, Brijesh, Ashish - see SEV-related changes in this series]
>
>
> On 13/01/2022 18:55, Daniel P. Berrangé wrote:
> > The AMD SEV build of EDK2 only emits a single file, intended to be
> >
> > mapped readonly. There is explicitly no separate writable VARS
> >
> > store for persisting non-volatile firmware variables.
> >
> >
> >
> > This can be used with QEMU's traditional pflash configuration
> >
> > mechanism by only populating pflash0, leaving pflash1 unconfigured.
> >
> > Conceptually, however, it is odd to be using pflash at all when we
> >
> > have no intention of supporting any writable variables. The -bios
> >
> > option should be sufficient for any firmware that is exclusively
> >
> > readonly code.
> >
> >
> >
> >
> >
> > A second issue is that the firmware descriptor schema does not allow
> >
> > for describing a firmware that uses pflash, without any associated
> >
> > non-volatile storage.
> >
> >
> >
> > In docs/interop/firmware.json
> >
> >
> >
> > 'struct' : 'FirmwareMappingFlash',
> >
> > 'data' : { 'executable' : 'FirmwareFlashFile',
> >
> > 'nvram-template' : 'FirmwareFlashFile' } }
> >
> >
> >
> > Notice that nvram-template is mandatory, and when consuming these
> >
> > files libvirt will thus complain if the nvram-template field is
> >
> > missing.
> >
> >
> >
> > We could in theory make nvram-template optional in the schema and
> >
> > then update libvirt to take account of it, but this feels dubious
> >
> > when we have a perfectly good way of describing a firmware without
> >
> > NVRAM, using 'FirmwareMappingMemory' which is intended to be used
> >
> > with QEMU's -bios option.
> >
> >
> >
> >
> >
> > A third issue is in libvirt, where again the code handling the
> >
> > configuration of pflash supports two scenarios
> >
> >
> >
> > - A single pflash image, which is writable
> >
> > - A pair of pflash images, one writable one readonly
> >
> >
> >
> > There is no support for a single read-only pflash image in libvirt
> >
> > today.
> >
> >
> >
> >
> >
> > This all points towards the fact that we should be using -bios
> >
> > to load the AMD SEV firmware build of EDK.
> >
> >
> >
> > The only thing preventing us doing that is that QEMU does not
> >
> > initialize the SEV firmware when using -bios. That is fairly
> >
> > easily solved, as done in this patch series.
> >
> >
> >
> > For testing I've launched QEMU in in these scenarios
> >
> >
> >
> > - SEV guest using -bios and boot from HD
> >
> > - SEV guest using pflash and boot from HD
> >
> > - SEV-ES guest using -bios and direct kernel boot
> >
> > - SEV-ES guest using pflash and direct kernel boot
> >
> >
> >
> > In all these cases I was able to validate the reported SEV
> >
> > guest measurement.
> >
> >
>
>
> I'm having trouble testing this series (applied on top of master commit
> 69353c332c):
> it hangs with -bios but works OK with pflash:
>
> Here's with -bios:
>
> $ sudo /home/dmurik/git/qemu/build/qemu-system-x86_64 -enable-kvm \
> -cpu host -machine q35 -smp 4 -m 2G \
> -machine confidential-guest-support=sev0 \
> -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x0 \
> -bios /home/dmurik/git/edk2/Build/AmdSev/DEBUG_GCC5/FV/OVMF.fd \
> -nographic \
> -global isa-debugcon.iobase=0x402 -debugcon file:ovmf-1.log \
> -monitor pty -trace 'enable=kvm_sev_*'
>
> char device redirected to /dev/pts/14 (label compat_monitor0)
> kvm_sev_init
> kvm_sev_launch_start policy 0x0 session (nil) pdh (nil)
> kvm_sev_change_state uninit -> launch-update
> kvm_sev_launch_update_data addr 0x7f42e9bff010 len 0x400000
> kvm_sev_change_state launch-update -> launch-secret
> kvm_sev_launch_measurement data
> PF6n7+Vujx5sW8PC6iMRtHXfpXdJ4osbcfYvoknu7gg4ypMqs727NTzG86Ft8Llu
> kvm_sev_launch_finish
> kvm_sev_change_state launch-secret -> running
>
>
> Here it hangs. The ovmf-1.log file is empty.
>
> Notice that kvm_sev_launch_update_data is called, so the new
> -bios behaviour is triggered correctly. But the guest doesn't
> start running.
Sorry, it seems I failed to test this properly before rushing into
sending last week. I was too focused on making sure the SEV measurement
was working and not the rest.
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 :|
