From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0607BC433DF for ; Fri, 26 Jun 2020 05:13:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CFBCC2075D for ; Fri, 26 Jun 2020 05:13:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="ovzR0esJ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726916AbgFZFN3 (ORCPT ); Fri, 26 Jun 2020 01:13:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42284 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725306AbgFZFN3 (ORCPT ); Fri, 26 Jun 2020 01:13:29 -0400 Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD74BC08C5C1 for ; Thu, 25 Jun 2020 22:13:28 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id c11so4444832lfh.8 for ; Thu, 25 Jun 2020 22:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QlzbbRoUsiNgCT+vaniYsWp4jyroliVG1Gc8oOdbYFc=; b=ovzR0esJWDDdDFb0jyp9YafS2plBJiJOi/tQHePW6RnDCVpGvwaXPT2LuDIrUgc3q2 19hx1drG3bg59u5lR7vRrAY6Nc3AUcx+SA/aJCuaCCFTu6aQdtWyThAj08WHnhyRw9Wh djgKIGc1yRDJDXqra3ydGeqbRZMcEZFebg+jyQ4oWw0einDd3cg+CJMMY2689VPNftDy KY4yrmpnhxAj1bfFechr6cP9x/fFBTtyBayKVePsUXqf/2OZ4PJ67B1KUbE2mAg7BxfK mB/Qg0/3cqSxnvejiVmmjeA9fcct413ZTfYjwUWRtxtT6icZvCUAo4HVFq7TgeRGMsn9 7Cgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QlzbbRoUsiNgCT+vaniYsWp4jyroliVG1Gc8oOdbYFc=; b=EbqVnDO1rTTbSc3E/5hUgyft9p0aywOAzH8X1iR1laYfi3HyhKdyA37iBdmQesLVSx 2/nrUlaqze5L1i58+0ZQyBVC6uo4Eyr8FnZIcZ+cQBAAY86lsrzBQfdxjcwIxSTIV7MW Yw/218H9/dQtji/YRnmXfEJK5XXKlHEzbBsR7Rm46Esfr+oq+yLgtJhqTjEvUD/TyzaD Xut2jsOLdbkIydNhim0Vcg2ogvg20vtQ2i/Afn/Y25FqcSQyyxx5nkGWDl9WvIN1ySoX m2e1pL17tS2Y+FPZ3PPN5bjV78hWcjQG7yxYBNi9SngqZe+ml1pNREVid1AXxff7mTNe qbJg== X-Gm-Message-State: AOAM533fo5AV8sAJQJwRlkN+x76rgJDeov5Aot8F4JDIOBe6BxelWSg5 bLUYXZWQOpaZ2ecpVIiOHCNAb9pEGkPT5atlsdS5oA== X-Google-Smtp-Source: ABdhPJzS7QYS1nugoTAgxtiZp65oSa+zQBCVvgk1F0KpTPkRj4nd5Gfi/Kfsl7MWSE54t3cG5t/3WfNBT0GZqy1mLws= X-Received: by 2002:a19:435b:: with SMTP id m27mr825249lfj.40.1593148407135; Thu, 25 Jun 2020 22:13:27 -0700 (PDT) MIME-Version: 1.0 References: <20200604175851.758-1-maxim.uvarov@linaro.org> <20200604175851.758-2-maxim.uvarov@linaro.org> <1592507935.15159.5.camel@HansenPartnership.com> <1592578844.4369.5.camel@HansenPartnership.com> <1593012069.28403.11.camel@HansenPartnership.com> <3aa8705a-0342-25ea-00c4-d5370d91ddb4@forissier.org> In-Reply-To: From: Sumit Garg Date: Fri, 26 Jun 2020 10:43:15 +0530 Message-ID: Subject: Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry To: Maxim Uvarov Cc: Jerome Forissier , James Bottomley , 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On Thu, 25 Jun 2020 at 18:22, Maxim Uvarov wrote: > > On Wed, 24 Jun 2020 at 18:44, Jerome Forissier wrote: > > > > > > > > On 6/24/20 5:21 PM, James Bottomley wrote: > > > On Wed, 2020-06-24 at 16:17 +0530, Sumit Garg wrote: > > >> Apologies for delay in my reply as I was busy with some other stuff. > > >> > > >> On Fri, 19 Jun 2020 at 20:30, James Bottomley > > >> wrote: > > > [...] > > >>> it's about consistency with what the kernel types mean. When some > > >>> checker detects your using little endian operations on a big endian > > >>> structure (like in the prink for instance) they're going to keep > > >>> emailing you about it. > > >> > > >> As mentioned above, using different terminology is meant to cause > > >> more confusion than just difference in endianness which is manageable > > >> inside TEE. > > >> > > >> And I think it's safe to say that the kernel implements UUID in big > > >> endian format and thus uses %pUb whereas OP-TEE implements UUID in > > >> little endian format and thus uses %pUl. > > > > > > So what I think you're saying is that if we still had uuid_be and > > > uuid_le you'd use uuid_le, because that's exactly the structure > > > described in the docs. But because we renamed > > > > > > uuid_be -> uuid_t > > > uuid_le -> guid_t > > > > > > You can't use guid_t as a kernel type because it has the wrong name? > > > > Let me try to clear the confusion that I introduce myself I believe :-/ > > IMO: > > > > - optee_register_device(const uuid_t *device_uuid) *is* the correct > > prototype. > > - device_uuid is *guaranteed* to be BE because OP-TEE makes this > > guarantee (it converts from its internal LE representation to BE when > > enumerating the devices, but it doesn't matter to the kernel). > > - Therefore %pUb is the correct format. > > > > I'm sorry for doubting the BE order initially. I am so used to OP-TEE > > using LE internally, that I missed the fact that we have an explicit > > conversion... > > > > Does this sound good? > > > > Thanks, > > -- > > Jerome > > I think your description is correct. But I think this problem would > be solved outside of the current patchset. > All places should use one single format (LE): I guess you missed the point that uuid_t is implemented in BE format in the kernel which is compliant as per RFC 4122. > - internal optee representation; > - device enumeration pta; > - this kernel driver which creates sysfs entry and sets > uid_copy(&optee_device->id.uuid, device_uuid); > - matching function; > - drivers use UUID_INIT(); See carefully the implementation of UUID_INIT() which is in BE format. -Sumit > > In that way everything will be consistent. But it will require > changing other pieces, not just the kernel. While > these patches add functionality to support current device enumeration > in optee os. > So I think this version is ok to be applied. > > Regards, > Maxim.