Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1594960ybt; Thu, 18 Jun 2020 12:24:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwiUBknELiMDCZApx2sBLXLiZcRuKxCF6nDfOiF2Owqt8X8wtftfY0s48d99G7J7upBaVb X-Received: by 2002:a17:906:c455:: with SMTP id ck21mr216299ejb.342.1592508255340; Thu, 18 Jun 2020 12:24:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592508255; cv=none; d=google.com; s=arc-20160816; b=YyD9sqRW4Y6fdykoC8OVKYP+Ke2VEmX7n4s1mQy3d7DE3L7fM+exLTTxb5cjXKmp27 DnO8HazuQxLJ6ImGgNcUJMPwhKSoN/oaDMNgXElYKEnpv7yt84L7tdTKqGwGILZQgPf3 SKbfQg4M7vdiOfqPBNYAIHTQQK5I8oFSZm3Pi95PbV4mHf08gPzunYYnxAeSSTQJvZlB +6hM3JEtvwvNCDs5ahMJq1fApxcI1SOceu4SBrQc3LVhDQ1gNgivxqJsSCOnCFfiZnTC Hx0cnyaKuAVcbKSxGnUaXd9f3wPKE9PH44iJ1hS26a9YR1U5aoxCLk9yqzmR9QEWAqNV BQ+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:dkim-signature; bh=2wKUu0KbE+FbfxBcK/oVaRYNP4zBfI/2fclZihHwBDs=; b=yDjJBXDM+ViUfjAF2Ya6NzBR2ZTeidX1kGG4RgWMLhClwVXKXA6yXLcf5lZaGmjZWf FbH9OuZo6OMWvUtrf5am6tm2H4dJbQKnKxsZ7a3P9C7eTBbOKUanuMMKrr4Y8hcSvtms 0NNMej685MRTOg3G+diksXitXbEmwVcAzdhQUBfbpdNNBhIwMU2PycvpY2oJX5YRM0RY hgYT/XqtXnhPrJ1MqOSZoAIyGmWOzX/VDC6wXBDyloEIfb2GJxKnj1zHGGmwL+0a1pzK 66R5YBfCd6Wbm1GJdZR0InO5s7At2lHYGE5QhsO+YWsbNAjsx8dAfWDNH8rJ+r24RdNb vRxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=nBOIJx1b; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=k6XQ29Ct; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g14si2339702edu.222.2020.06.18.12.23.53; Thu, 18 Jun 2020 12:24:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=nBOIJx1b; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=k6XQ29Ct; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728161AbgFRTS7 (ORCPT + 99 others); Thu, 18 Jun 2020 15:18:59 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:44494 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726940AbgFRTS7 (ORCPT ); Thu, 18 Jun 2020 15:18:59 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id DE3C58EE181; Thu, 18 Jun 2020 12:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1592507938; bh=x6FrWvTnfZ/GlB+YCnL0wfn/a3OsPRk4p9KX7tVZJcw=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=nBOIJx1bYA6OGVfRlBmwSqgci8hN3+m/kBL3778yteglY+55vT9QmYVTTp2sCegj1 kgR8v6EgDQfBGbPxc+mL3ak/CdmFrxj+/uMY4f1ijCxsbkhSoPUxbAoAogzOO9WW0G Xys3cXGbzvrUh85bNE3UBG7sFWL0+fsR9PpxWz5c= Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5146Snh5mdFF; Thu, 18 Jun 2020 12:18:57 -0700 (PDT) Received: from jarvis (unknown [216.116.10.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id B7E538EE0EA; Thu, 18 Jun 2020 12:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1592507937; bh=x6FrWvTnfZ/GlB+YCnL0wfn/a3OsPRk4p9KX7tVZJcw=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=k6XQ29CtsLtVtkr0vTwC4aNzP/mq62lwKBJl7I1OKezqdKQl6DtLqdMbNLbbPxgFB 9GeFOBA4uNFgBq0RTM/pKjqL9IeS45WIc1XyBPuknSVz8JUFBZsJH7hr9xhGz4LdK7 XTjwUxUENpqWTlQ3pJBZESm4YEd3+EEr/zxLjSAs= Message-ID: <1592507935.15159.5.camel@HansenPartnership.com> Subject: Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry From: James Bottomley To: Sumit Garg , Jerome Forissier Cc: Maxim Uvarov , Greg Kroah-Hartman , Linux Kernel Mailing List , Jarkko Sakkinen , Arnd Bergmann , "tee-dev @ lists . linaro . org" , Jason Gunthorpe , linux-integrity@vger.kernel.org, peterhuewe@gmx.de Date: Thu, 18 Jun 2020 12:18:55 -0700 In-Reply-To: References: <20200604175851.758-1-maxim.uvarov@linaro.org> <20200604175851.758-2-maxim.uvarov@linaro.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2020-06-18 at 10:42 +0530, Sumit Garg wrote: > On Thu, 18 Jun 2020 at 10:29, Sumit Garg > 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 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