On 22/08/2025 2:47 pm, Teddy Astie wrote: > Currently, hvmloader uses SMBIOS 2.4, however, when using OVMF, the > SMBIOS is patched to 2.8, which has clarified the UUID format (as GUID). > > In Linux, if the SMBIOS version is >= 2.6, the GUID format is used, else > (undefined as per SMBIOS spec), big endian is used (used by Xen). Therefore, > you have a endian mismatch causing the UUIDs to mismatch in the guest. > > $ cat /sys/hypervisor/uuid > e865e63f-3d30-4f0b-83e0-8fdfc1e30eb7 > $ cat /sys/devices/virtual/dmi/id/product_uuid > 3fe665e8-303d-0b4f-83e0-8fdfc1e30eb7 > $ cat /sys/devices/virtual/dmi/id/product_serial > e865e63f-3d30-4f0b-83e0-8fdfc1e30eb7 > > This patch updates the SMBIOS version from 2.4 to 2.6 and fixup the UUID > written in the table; which effectively fix this endianness mismatch with > OVMF; while the UUID displayed by Linux is still the same for SeaBIOS. > > Signed-off-by: Teddy Astie <teddy.as...@vates.tech> > --- > This effectively changes the UUID seen with UEFI guests as it was > actually inconsistent with SeaBIOS and SMBIOS expectations. > ---
I agree this is a real bug and needs fixing. However, ... > tools/firmware/hvmloader/smbios.c | 20 ++++++++++++++++++-- > 1 file changed, 18 insertions(+), 2 deletions(-) > > diff --git a/tools/firmware/hvmloader/smbios.c > b/tools/firmware/hvmloader/smbios.c > index 6bcdcc233a..f4822ae6f8 100644 > --- a/tools/firmware/hvmloader/smbios.c > +++ b/tools/firmware/hvmloader/smbios.c > @@ -352,7 +352,7 @@ smbios_entry_point_init(void *start, > memcpy(ep->anchor_string, "_SM_", 4); > ep->length = 0x1f; > ep->smbios_major_version = 2; > - ep->smbios_minor_version = 4; > + ep->smbios_minor_version = 6; > ep->max_structure_size = max_structure_size; > ep->entry_point_revision = 0; > memcpy(ep->intermediate_anchor_string, "_DMI_", 5); > @@ -462,7 +462,23 @@ smbios_type_1_init(void *start, const char *xen_version, > p->version_str = 3; > p->serial_number_str = 4; > > - memcpy(p->uuid, uuid, 16); > + /* > + * Xen uses OSF DCE UUIDs which is fully big endian, however, > + * GUIDs (which requirement is clarified by SMBIOS >= 2.6) has the > + * first 3 components appearing as being little endian and the rest > + * as still being big endian. ... this is not an accurate statement. Xen specifically tries to treat a xen_domain_handle_t as an opaque blob. The only two areas I can see ascribing any structure are the 'q' debugkey (not exactly a strong ABI statement), and the arinc635 scheduler whose use is buggy (uuids are not unique in Xen; it's the domid which is). It is an error that a format isn't stated, but the format comes from the toolstack. We'd better hope that all toolstacks use OSF DCE UUIDs, or this is going to badly wrong. And on that note, the toolstacks are not the same. Xapi for example uses reads 16 bytes out of /dev/urandom. Whatever we end up doing, the fix must include a change to xen/include/public/version.h stating the format of the UUID. ~Andrew
