On Thu, Jun 07, 2018 at 11:36:20AM +0100, Daniel P. Berrangé wrote: > On Thu, Jun 07, 2018 at 11:32:18AM +0100, Richard W.M. Jones wrote: > > On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote: > > > Something that I haven't seen mentioned in the thread - and this > > > looks like as good a point as any to jump in - is that for q35 > > > guests using EFI as well as aarch64 guests the "one click import" > > > experience requires not only hints about the machine (and firmware!) > > > type, but also a copy of the EFI variable store: > > > > > > $ virt-builder fedora-27 --arch aarch64 --notes > > > Fedora® 27 Server (aarch64) > > > > > > [...] > > > > > > You will need to use the associated UEFI NVRAM variables file: > > > http://libguestfs.org/download/builder/fedora-27-aarch64-nvram.xz > > > > This is true, although only sometimes. If the bootloader[*] has a > > working fallback path then usually it is able to boot and reset the > > UEFI varstore back to the correct values. We have had bugs before > > where the fallback path was not working, eg: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1353689 (yours!) > > https://bugzilla.redhat.com/show_bug.cgi?id=1558793 > > > > Another problem which Laszlo mentioned is the varstore isn't portable > > between UEFI implementations, or if the UEFI is compiled with > > different options. You can even imagine shipping multiple > > varstores(!) which argues for a tar-like format. > > Could we perhaps imagine shipping the actual UEFI bios, rather > than only the varstore.
That's pretty unusual, UEFI is designed to abstract away the hardware. It normally ships with the hardware. I don't think it's a good idea to stick firmware itself in the image: updating guest images is already a problem, at least we can easily fix firmware bugs by dnf update on the host. > The bios blob runs in guest context, > so there shouldn't be able security concerns from hosting > vendors with running user provided bios. It seems possible that users that do supply their own firmware will want to save it with the image. I don't think we should do it for the standard firmware. > Mostly its a matter > of confidence that the interface between bios & qemu is stable > which feels easier than assuming varstore vs different bios is > portable. IIRC, shipping actual UEFI BIOS is something that was > desirable for AMD SEV usage. For SEV storing the un-encrypted binary, having QEMU read it out and write it into guest memory isn't any better than shipping it with QEMU. > > 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 :|
