Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?

[Laszlo Ersek]

On 06/07/18 12:54, Andrea Bolognani wrote:
> On Thu, 2018-06-07 at 11:36 +0100, Daniel P. Berrangé wrote:
>> On Thu, Jun 07, 2018 at 11:32:18AM +0100, Richard W.M. Jones wrote:
>>> 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.  The bios blob runs in guest context,
>> so there shouldn't be able security concerns from hosting
>> vendors with running user provided bios. 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.
> 
> That sounds sensible, and further reinforces the idea that we
> need way more than a single string baked into the qcow2 file.
> 

Sorry for arriving late (thanks Rich for the Fwd).

The contents of the non-volatile UEFI variables should be considered
part of (permanent) guest state, such as disk contents. Therefore I'd
argue for bundling the varstore file with the disk image(s).

In turn, the best way to ensure comaptibility between varstore and
firmware binary is to just bundle the firmware binary as well. It's
generally not large (x86) or if it is, it compresses extremely well
(aarch64). For extra politeness, image providers can bundle a text file
with their firmware build options (like a kernel config), possibly even
a JSON document conforming to the new firmware schema (qemu commit
3a0adfc9bfcf), but that's not a hard requirement I guess.

If such a VM is to be migrated between hosts, I'd expect the host admin
to take care of installing the fw binary on all eligible hosts.


Regarding compat between QEMU and firmware binary, I see three cases:

(1) Static requirements presented by the firmware for the QEMU
configuration. (Such as -D SMM_REQUIRE.) With the domain configuration
captured one way or another alongside the disk image anyway, this should
not be a problem.

(2) New firmware launched on old QEMU. The firmware generally detects or
negotiates features with QEMU, so this should be safe.

(Discounting firmware regressions, of course -- for example, search
<https://www.mail-archive.com/address@hidden/msg471901.html> for
the string "I messed up".)

(3) Old firmware launched on new QEMU. This scenario has given us a lot
more grief than (2), but I think for the appliance distribution use
case, it can be folded into case (1) above -- specify the machine type
too in the domain config, and that should be compatible with the old
firmware.

(The handling of (3) is not uniform between upstream QEMU and various
downstreams. For example, consider
<https://bugs.launchpad.net/qemu/+bug/1715700>. This was a latent bug in
OVMF that got exposed by a new QEMU (due to a valid QEMU change), even
when using old machine types. The upstream solution was to fix edk2 and
stick with QEMU as-was (although the agreement around that hadn't been
universal). Conversely, one downstream solution was to restrict the
otherwise valid QEMU change to new machine types
<https://bugzilla.redhat.com/show_bug.cgi?id=1489800#c5>.)


All in all I agree with Daniel's proposal; it seems to be the most
robust one.

And, I too recall that, under AMD SEV, users will be supposed to, or
allowed to, provide their own firmware binaries.

Thanks!
Laszlo