bugdmidecode - Bugs: bug #55510, UUID and byte ordering - again


bug #55510: UUID and byte ordering - again

Submitter:  None
Submitted:  Fri 18 Jan 2019 06:30:49 PM UTC
Category:  None Severity:  2 - Minor
Item Group:  None Status:  Wont Fix
Privacy:  Public Assigned to:  khali
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:
       No canned response available


Tue 29 Jan 2019 01:13:04 PM UTC, comment #3: 
Jean Delvare <khali>
Project Administrator
Tue 22 Jan 2019 10:30:48 AM UTC, comment #2: 

This is what I plan to add to the manual page. Please review and let me know if you have any concern or suggestions of improvement.


There is some ambiguity about how to interpret the UUID fields prior to SMBIOS specification version 2.6. There was no mention of byte swapping, and RFC 4122 says that no byte swapping should be applied by default. However, SMBIOS specification version 2.6 (and later) explicitly states that the first 3 fields of the UUID should be read as little-endian numbers (byte-swapped). Furthermore, it implies that the same was already true for older versions of the specification, even though it was not mentioned. In practice, many hardware vendors were not byte-swapping the UUID. So, in order to preserve compatibility, it was decided to interpret the UUID fields according to RFC 4122 (no byte swapping) when the SMBIOS version is older than 2.6, and to interpret the first 3 fields as little-endian (byte-swapped) when the SMBIOS version is 2.6 or later. The Linux kernel follows the same logic.

Jean Delvare <khali>
Project Administrator
Tue 22 Jan 2019 09:28:11 AM UTC, comment #1: 

When I saw the change of UUID byte ordering in SMBIOS specification version 2.6 (which the specification ironically calls a "clarification", but it is a change, really), I predicted that it would cause a lot of confusion for the following 10 years. That was in June 2008 and we are still discussing this, so I was sadly correct.

Please don't be angry after me, or after dmidecode, or after the Linux kernel (which unsurprisingly follows the same logic, as I am in charge of both). If you want to blame someone, blame the DMTF committee for their decision to change the UUID byte ordering and infringing RFC 4122. They claim that it was dictated by a general consensus among the PC industry but my own experience is that most hardware vendors were using the RFC 4122 byte order (no swapping). It is the software vendors (Microsoft and the firmware folks at Intel) who messed it up in the first place. They live in a little-endian world since they were born and they believe the whole world thinks little-endian. But that's not the case, and we have something called network byte order for a reason (portability, as it is called).

The change you request would only affect SMBIOS implementations 2.5 and earlier. I doubt there are many machines still in use which do not use SMBIOS 2.6 or more recent, especially in professional environments (where UUIDs actually matter). So this is a discussion you should have brought on the table 10 years ago. Discussing it now it is a waste of time. This ship has sailed already as far as I am concerned.

If the problem happens in virtual machines which emulate a pre-2.6 DMI table, then this alone would be a good reason for them to start emulating a 2.6 DMI table instead. That's an issue to be addressed in the VM server software, not dmidecode.

Anyway, looking back at the decision I took back then, I still think I did the right thing. SMBIOS specifications prior to 2.6 did not mention any swapping, so sticking to RFC 4122 made sense. SMBIOS specifications 2.6 and later are unambiguous about the requirement to byte-swap certain fields of the UUID. So from my perspective, each version of the specification considered separately is unambiguous and there's only one correct order to decode the UUID field for each SMBIOS version. It is up to the hardware vendors and software authors to do the right thing.

Your proposal would have side effects that would cause trouble anyway. Callers of "dmidecode -s system-uuid" assume that this command will return a single UUID, and only a UUID (no comment attached), which they can store or use for comparison directly. If that command would return 2 UUIDs with annotations, that would break this interface for all callers (including the restricted software you mentioned yourself). This isn't the kind of change that is done lightly. Actually I received flames recently for doing an interface change that was way less intrusive than what you are asking for.

As a side note... The "U" in "UUID" means "unique". If you accept the idea that each machine can have 2 different UUIDs, then you also accept the idea that the same UUID can be used by 2 different machines. Which totally voids the point of having UUIDs, as uniqueness is gone.

As another side note, the same Anthony Hay you quoted, wrote in another blog post that SMBIOS UUIDs are highly unreliable in practice and should never be relied upon. As a matter of fact, the company where I work is using the combination of serial number and asset tag to uniquely identify our hardware equipment in their asset management tool. Not UUID.

The only thing I agree with in your long request is that the "problem" could be documented in the manual page. I'll look into that.

Jean Delvare <khali>
Project Administrator
Fri 18 Jan 2019 06:30:49 PM UTC, original submission:  

I request a different approach to the byte ordering confusion in the early SMBIOS specification, prior to version 2.6.

In the current approach, for SMBIOS versions prior to 2.6, the originally recommended "big endian" byte order is displayed, and the "mixed" byte ordering is displayed for subsequent SMBIOS versions.

The problem with this approach is, unless the user has been "bitten" by this change in the SMBIOS specification, they are very likely to have no idea that there are two different interpretations of the UUID.

To avoid this problem, I suggest that 1) a BIG FAT NOTE be added to the dmidecode man page, describing the problem, and that 2) both versions of the UUID be displayed in the dmidecode output, annotated as, say, "big endian" and "mixed endian".

Anthony Hay offers a discussion of the issue, which might be referenced:

In this way, the user is put on notice that there exist alternative expressions of the UUID, and can then investigate, as needed.  And, the "alternate" version of the UUID, whichever one that might be, is displayed right there, without having to manually make revisions, lest that require additional error-prone thought.

Please keep in mind, probably the only time anyone cares what the actual UUID is is when communicating with another person, in particular, as when communicating with Customer Support for the hardware in question, or for some restricted software running on that hardware.  We can be pretty certain that this Customer Support person has no concept of byte ordering or SMBIOS version changes.  And then, if the UUID read from the hardware differs from the UUID expected by Customer Support - it is unpleasant.  By showing both versions of the UUID, at worst, the user can read-off both versions to the Customer Support person, and hope that one of the two versions is in the correct format.  Customer Support is only going to attempt to "verify" the UUID given, whatever it is.

An alternative to this solution would be to only show both UUID versions for SMBIOS versions prior to version 2.6, assuming everyone is fairly certain that the subsequent SMBIOS specifications are always interpreted with the "mixed" byte order by all hardware manufacturers - but, maybe not a good bet.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by khali (Posted a comment)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-29 khali StatusNeed Info Wont Fix
        Open/ClosedOpen Closed
    2019-01-22 khali Severity3 - Normal 2 - Minor
        StatusNone Need Info
        Assigned toNone khali

    Back to the top

    Powered by Savane 3.9