From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::342; helo=mail-wm1-x342.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 214E72194D387 for ; Thu, 18 Oct 2018 02:24:36 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id i8-v6so4659050wmg.0 for ; Thu, 18 Oct 2018 02:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=0VAR3d/fuf2LqY9oSjhe3skx1ShA5AQVxM0hwTcVe6I=; b=M18MLdzXgIIAeg2u3a2vkv2AyIfoyTG40vqRp4ExAAGXrq/nq661ATwc3n5s5UMw4C oqxsPeyfcc063dnrpwogVqGKNJaubIW5NEoYuU1wxrsPnFHNdJoIu5jbNlxIca2jXKlC /bs0nLu17BTBhVQGcgdFrAHNhr0trE6I8Tm68= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0VAR3d/fuf2LqY9oSjhe3skx1ShA5AQVxM0hwTcVe6I=; b=uJB+nSo9KqQX0RiMKM6UJ9CKmSXHOJ0OAh4+WfHyKDEU+CgQkMs84rlLDf7+7INl9a 3ZiGcou3+JPxBKgdcrTpFoLftt8tHl/dIGMMQjH6nQH7xqrng+DawfngLl4K9Hp7bPzj 21qKIfzV3v/bqSascsiKao/XYiHCBI7paUZkmFWDCjThFLP72Q6irpRe31QVjOp7mBO3 RSGqXumQDuiQkNQJItkcznF29WEolUPCBvFu1hyPkg70Resh1LjOEzOzuNggLdYkzqmo X7o8UfwSAYFmdp2EVnC/pRv5k+d6EIpqyGhcXYOwJqkjM/n17R/VS104AFeucTIdgIHh KA/Q== X-Gm-Message-State: ABuFfohi4Cks2CY9P9x8e1IKyjWKBDklGdkxFrX+vxF0J+ecHZrcKbcI gsPSgKWsNMvdCcLvkZj4Dfl8VQ== X-Google-Smtp-Source: ACcGV622yscBCE0PMLd0v0rU7cY373lr28RKItOAuLPCMloGVhEaiPUrnJ0Rt0zzNGbSi6ENZn5svw== X-Received: by 2002:a1c:b743:: with SMTP id h64-v6mr6484158wmf.26.1539854675394; Thu, 18 Oct 2018 02:24:35 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id y138-v6sm2914735wmd.2.2018.10.18.02.24.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 18 Oct 2018 02:24:34 -0700 (PDT) Date: Thu, 18 Oct 2018 10:24:32 +0100 From: Leif Lindholm To: Sumit Garg 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 Message-ID: <20181018092432.y7y2hvq5s4vdhmnv@bivouac.eciton.net> 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> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) 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:24:37 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Oct 18, 2018 at 02:43:37PM +0530, Sumit Garg wrote: > 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. That's a fair point. We could call it RFC4122_UUID for now. There could even be a case to add that to BaseLib at some point (but probably not while there is only one user). Regards, Leif > 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