From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::e41; helo=mail-vs1-xe41.google.com; envelope-from=sumit.garg@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 867E621173C6A for ; Thu, 18 Oct 2018 02:13:49 -0700 (PDT) Received: by mail-vs1-xe41.google.com with SMTP id r83so22607498vsc.4 for ; Thu, 18 Oct 2018 02:13:49 -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=FXHlecU2mHQbIe1QuGiYiIHPY/MZQx29nIQXRQD8pOY=; b=Sm9xaugROtoGrbeqSpoRXQW0243SuCxmMUKY+D3SOgm9im9pFB2KHxFMuqXiS4G8LR Nthzq4nM8zQcW87udAY7jEGzOtj1Zit0FVuXo4HY016R/rMi4zDOWPihrkWJTuB62Jnu Jcw5+Ff8LM/i/ceOMFC+t4x/L8xiGrHJXPS6o= 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=FXHlecU2mHQbIe1QuGiYiIHPY/MZQx29nIQXRQD8pOY=; b=Cv0O1NtgYqnopDn4k5ICw0mfoWbH+3zhusryUna5rTEU4eQw0g7Zeps4qcy/gFEPUX W8ns09Gko5Hci6HTHCug1GHOB4uiuJyf3KfeHWS8Ewip/Fqftnq8Iq6qSChKZ4bjnSbB EfAu6lOCJUzemftZiqWWpn/EDUvHHejnTRDo30cLiXruyrFG3dbwQgZ8hti7ALnDux3n 2HbC7aUAxVsd08F/gg+FXE62KqTViwr7484z5YHLcxzNXfoMual6WM9ppgLN48xgqXWK tONk2DJ4xLk3o7EmqNze1PhXTisKOiBkwmzaUrMl6vDTYlkfx2ki6/o4rLm56HGSoFYW 0eew== X-Gm-Message-State: ABuFfoh0aS7axbXhrq2XUqLXxDqZgfgq39we+nrNooeDAayn+ZL/TJ1R 1rRurMH0WtAncG+ZtTVObDbFR/V8dh++u98rdSp5Uw== X-Google-Smtp-Source: ACcGV63skCC3cZAXCuPK3NWNBxkz1jXCnmgO+/XNNt0IIgpjTN70KiXvd5gNG5M1YXgW5fSJ0FVWdpE/yxe4/kahxbU= X-Received: by 2002:a67:8c4a:: with SMTP id o71mr8472379vsd.55.1539854028468; Thu, 18 Oct 2018 02:13:48 -0700 (PDT) MIME-Version: 1.0 References: <1539148733-5426-1-git-send-email-sumit.garg@linaro.org> <1539148733-5426-2-git-send-email-sumit.garg@linaro.org> <20181018062343.w3343srhcq4dv65p@bivouac.eciton.net> <20181018083411.iplsdsrrswvuhacl@bivouac.eciton.net> In-Reply-To: <20181018083411.iplsdsrrswvuhacl@bivouac.eciton.net> From: Sumit Garg Date: Thu, 18 Oct 2018 14:43:37 +0530 Message-ID: To: Leif Lindholm Cc: edk2-devel@lists.01.org, Ard Biesheuvel , Michael D Kinney , tee-dev@lists.linaro.org, Daniel Thompson , Joakim Bech , Matteo.Carlini@arm.com, Achin.Gupta@arm.com, udit.kumar@nxp.com Subject: Re: [PATCH v4 1/1] ArmPkg/OpteeLib: Add APIs to communicate with OP-TEE X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 09:13:49 -0000 Content-Type: text/plain; charset="UTF-8" On Thu, 18 Oct 2018 at 14:04, Leif Lindholm wrote: > > On Thu, Oct 18, 2018 at 12:59:32PM +0530, Sumit Garg wrote: > > > So, looking at the OpTee sources, TEE_UUID is defined as a struct, to > > > exactly the same layout as the EFI_GUID type (which is a typedef of > > > the GUID struct). Could we add a OPTEE_UUID typedef for the same > > > struct in OpteeLib.h? > > > > > > Since it comes in as an OPTEE_MESSAGE_PARAM_VALUE, alignment is > > > already guaranteed to be 64-bit. > > > > > > (This also deserves a comment explaining how EFI_GUID basically > > > follows rfc4122, but uses little-endian for the timestamp fields.) > > > > Actually, OP-TEE also uses little-endian format for timestamp fields. > > You can refer to [1] for conversion from network byte order (octets) > > to little-endian and vice-versa. > > > > So for communications among secure world and non-secure world it uses > > network byte order for UUID/GUID to comply with rfc4122. > > > > [1] https://github.com/OP-TEE/optee_os/blob/master/core/tee/uuid.c > > Huh, ok. That's good to know. > It does however not change my comments. Since we're dealing with data > structures of a known layout, I am not a fan of treating them as byte > arrays. > But calling UUID struct with swapped timestamp as OPTEE_UUID would also be misnomer. I am not sure regarding appropriate naming for that struct. On the other hand, we have byte array of 16 octets as per network byte order complying with rfc4122 which also doesn't imply swapped timestamp. -Sumit > / > Leif