lists.openwall.net   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  linux-cve-announce  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:   Thu, 18 Jun 2020 12:18:55 -0700
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Sumit Garg <sumit.garg@...aro.org>,
        Jerome Forissier <jerome@...issier.org>
Cc:     Maxim Uvarov <maxim.uvarov@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Arnd Bergmann <arnd@...aro.org>,
        "tee-dev @ lists . linaro . org" <tee-dev@...ts.linaro.org>,
        Jason Gunthorpe <jgg@...pe.ca>,
        linux-integrity@...r.kernel.org, peterhuewe@....de
Subject: Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry

On Thu, 2020-06-18 at 10:42 +0530, Sumit Garg wrote:
> On Thu, 18 Jun 2020 at 10:29, Sumit Garg <sumit.garg@...aro.org>
> wrote:
[...]
> > > typedef struct
> > > {
> > >         uint32_t timeLow;
> > >         uint16_t timeMid;
> > >         uint16_t timeHiAndVersion;
> > >         uint8_t clockSeqAndNode[8];
> > > } TEE_UUID;
> > > 
> > > (GlobalPlatform TEE Internal Core API spec v1.2.1 section 3.2.4)
> > > 
> > > - The spec does not mandate any particular endianness and simply
> > > warnsabout possible issues if secure and non-secure worlds differ
> > > in endianness.
> > > - OP-TEE uses %pUl assuming that host order is little endian
> > > (that is true for the Arm platforms that run OP-TEE currently).
> > > By the same logic %pUl should be fine in the kernel.
> 
> I think Linux adheres to this RFC [1] for UUID byte order. See below
> snippet from section: "Layout and Byte Order":
> 
>    The fields are encoded as 16 octets, with the sizes and order of
> the
>    fields defined above, and with each field encoded with the Most
>    Significant Byte first (known as network byte order).  Note that
> the
>    field names, particularly for multiplexed fields, follow
> historical
>    practice.

Actually, that's not quite true.  We used to support both little and
big endian uuids until we realised it was basically microsoft vs
everyone else (as codified by RFC 4122).  Now we support UUIDs which
are big endian and GUIDs which are little endian.  This was the commit
that sorted out the confusion:

commit f9727a17db9bab71ddae91f74f11a8a2f9a0ece6
Author: Christoph Hellwig <hch@....de>
Date:   Wed May 17 10:02:48 2017 +0200

    uuid: rename uuid types

so if you're using a little endian uuid, you should probably be using
GUID for TEE_UUID.

James

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ