Re: [Qemu-devel] Byte ordering of VM Generation ID in Windows VMs

[Laszlo Ersek]

On 07/05/18 18:43, Richard W.M. Jones wrote:
> On Thu, Jul 05, 2018 at 04:20:33PM +0200, Laszlo Ersek wrote:
>> QEMU does the right thing. If other hypervisors don't do this -- while
>> still taking and displaying the value in UUID / GUID textual format --,
>> they are wrong. The VMGENID spec from Microsoft
>> <http://go.microsoft.com/fwlink/?LinkId=260709> specifically mentions
>> "GUID".
> 
> The MSFT spec does mention GUID, but it seems to me that it's only
> using GUID as an incidental example -- ie. that you might use the VM
> Generation ID to generate a GUID.  Outside that example it
> consistently refers to the VM Gen ID as a 128-bit integer.  It also
> says that it could be used as a "high entropy random data source",
> which is not in fact true if it's a UUID.

I don't have additional points regarding whether Microsoft genuinely did
or didn't think of VMGENID in terms of UUID.

However, the fact that the fields of the *original* UUID definition have
been repurposed for fully random bytes is not an argument against. Just
because we nowadays populate all those bytes from a PRNG (sort-of),
thereby ignoring their original field names, we still call the structure
UUID and we still preserve the internal field boundaries. For example,
in UEFI (the spec), we have

typedef struct {
  UINT32 Data1;
  UINT16 Data2;
  UINT16 Data3;
  UINT8 Data4[8];
} EFI_GUID;

and in the edk2 codebase, whenever a new GUID is needed for any purpose,
we're supposed to get one by running "uuidgen". From the manual:

       There  are two types of UUIDs which uuidgen can generate: time-
       based UUIDs and random-based UUIDs.  By  default  uuidgen  will
       generate  a  random-based  UUID if a high-quality random number
       generator is present.  Otherwise, it will choose  a  time-based
       UUID.   It  is possible to force the generation of one of these
       two UUID types by using the -r or -t options.

> It has to be said that after reading the spec again [the MSFT spec,
> not qemu's spec] and what other hypervisors are doing, I'm not sure
> qemu is doing the right thing here.

That's the thing about specs -- interpretation. I've read the vmgenid
spec several times as well, and I've always understood it as Microsoft
meaning UUID / GUID as a primary representation for VMGENID. I may have
been biased by UUID/GUID usage in UEFI.

When the feature was being developed for QEMU, we struggled with the
interpretation of a good number of other bits as well; hence the
"Requirements" section of QEMU's spec: "this is how we understood it".
Without an open list to discuss things with Microsoft, sometimes we can
only guess what is a "likely faithful" interpretation, and test it in
practice.

I still believe QEMU's current interpretation is the right one; but I
can't prove it.

Laszlo