[PATCH] dmi, Use little-endian for sysfs PRODUCT UUID

[PATCH] dmi, Use little-endian for sysfs PRODUCT UUID

[Prarit Bhargava]

I noticed this discrepancy between the output of 'dmidecode -t 1 | grep
UUID' and the output of /sys/class/dmi/id/product_uuid:

[root@intel-mahobay-01 ~]# cat /sys/class/dmi/id/product_uuid
001320FB-4C2D-0013-20FB-4C2D001320FB
[root@intel-mahobay-01 ~]# dmidecode | grep UUID
        UUID: FB201300-2D4C-1300-20FB-4C2D001320FB

Section 7.2.1, "System -- UUID" of the SMBIOS Specification (version
2.7.1) states:

Although RFC 4122 recommends network byte order for all fields, the PC
industry (including the ACPI, UEFI, and Microsoft specifications) has
consistently used little-endian byte encoding for the first three
fields: time_low, time_mid, time_hi_and_version. The same encoding, also
known as wire format, should also be used for the SMBIOS representation of
the UUID.

The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be
represented as:

33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.

However, A comment in the dmidecode utility contains the following warning:

	 * As of version 2.6 of the SMBIOS specification, the first 3
	 * fields of the UUID are supposed to be encoded on little-endian.
	 * The specification says that this is the defacto standard,
	 * however I've seen systems following RFC 4122 instead and use
	 * network byte order, so I am reluctant to apply the byte-swapping
	 * for older versions.

Apply this same logic to the output of the kernel's representation for SMBIOS
Product UUID.

After the patch is applied on a system with SMBIOS version 2.6,

[root@intel-mahobay-01 ~]# cat /sys/class/dmi/id/product_uuid
FB201300-2D4C-1300-20FB-4C2D001320FB
[root@intel-mahobay-01 ~]# dmidecode | grep UUID
	UUID: FB201300-2D4C-1300-20FB-4C2D001320FB

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
---
 drivers/firmware/dmi_scan.c |   21 +++++++++++++++++++--
 1 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 153980b..ef41d90 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -15,6 +15,9 @@
  */
 static char dmi_empty_string[] = "        ";
 
+/* SMBIOS version in MMmm format */
+static u16 smbios_version;
+
 /*
  * Catch too early calls to dmi_check_system():
  */
@@ -169,7 +172,18 @@ static void __init dmi_save_uuid(const struct dmi_header *dm, int slot, int inde
 	if (!s)
 		return;
 
-	sprintf(s, "%pUB", d);
+	/*
+	 * As of version 2.6 of the SMBIOS specification, the first 3
+	 * fields of the UUID are supposed to be encoded on little-endian.
+	 * The specification says that this is the defacto standard,
+	 * however we've seen systems following RFC 4122 instead and use
+	 * network byte order, so do not apply the byte-swapping
+	 * for older versions.
+	 */
+	if (smbios_version >= 0x0206)
+		sprintf(s, "%pUL", d);
+	else
+		sprintf(s, "%pUB", d);
 
         dmi_ident[slot] = s;
 }
@@ -411,9 +425,12 @@ static int __init dmi_present(const char __iomem *p)
 		 * DMI version 0.0 means that the real version is taken from
 		 * the SMBIOS version, which we don't know at this point.
 		 */
-		if (buf[14] != 0)
+		if (buf[14] != 0){
 			printk(KERN_INFO "DMI %d.%d present.\n",
 			       buf[14] >> 4, buf[14] & 0xF);
+			smbios_version = (((buf[14] >> 4) << 8) +
+					  (buf[14] & 0xF));
+		}
 		else
 			printk(KERN_INFO "DMI present.\n");
 		if (dmi_walk_early(dmi_decode) == 0) {
-- 
1.7.1

Re: [PATCH] dmi, Use little-endian for sysfs PRODUCT UUID

[Matthew Garrett]

On Mon, Mar 26, 2012 at 02:12:51PM -0400, Prarit Bhargava wrote:
> Although RFC 4122 recommends network byte order for all fields, the PC
> industry (including the ACPI, UEFI, and Microsoft specifications) has
> consistently used little-endian byte encoding for the first three
> fields: time_low, time_mid, time_hi_and_version. The same encoding, also
> known as wire format, should also be used for the SMBIOS representation of
> the UUID.

There's some potential for breakage here. Perhaps add an additional 
attribute that adds the purely little-endian UUID?

-- 
Matthew Garrett | mjg59@srcf.ucam.org