lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 30 Aug 2017 13:01:28 -0700
From:   Andy Lutomirski <>
To:     Christoph Hellwig <>
Cc:     Andy Lutomirski <>,
        Andy Shevchenko <>,
        Andy Shevchenko <>,
        Darren Hart <>,
        Platform Driver <>,
        "Rafael J. Wysocki" <>,
        "" <>
Subject: Re: [PATCH v1] platform/x86: wmi: Switch to use new generic UUID API

On Wed, Aug 30, 2017 at 5:25 AM, Christoph Hellwig <> wrote:
> On Sun, Aug 13, 2017 at 08:34:56AM -0700, Andy Lutomirski wrote:
>> > This specification defines a Uniform Resource Name namespace for
>> > UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally
>> > Unique IDentifier).
>> No, that still matches what I thought I knew: "UUID" and "GUID" are synonyms.
> Well, in practice they aren't - wintel GUID are big endian, and
> RFC4122 clearly states it is big endian, although it uses the term
> "network byte order":

What I'm saying is: I agree that "RFC4122 UUID" and "wintel GUID" are
different, but the new structs aren't called "RFC4122 UUID" and
"wintel GUID" - they're called "uuid" and "guid".  I think the latter
is very far from intuitive.  I read the wmi patches several times
before I figured out that they were even potentially correct.

>> typedef whatever uuid_t;
>> typedef something_different uuid_le;  /* which already existed */
>> extern void uuid_le_to_uuid(uuid_t *out, uuid_le *in);
>> extern void uuid_to_uuid_le(...);
> What's the point of converting between a RFC4122 UUID and a Wintel
> GUID?  They are used for entirely different things.

I can see at least two clean ways to design the API:

1. Make them totally separate.  Have a function to convert a string to
a uuid_le (or a guid_le or whatever you want to call it, as long as
"le" or perhaps "wintel" is involved so it's obvious.)  Have another
function to convert back.  Teach printk to understand %pULE.

2. Have a function to convert back and forth so that kernel code uses
the real RFC4122 UUID for internal representations and keep just %pU.


Powered by blists - more mailing lists