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::343; helo=mail-wm1-x343.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 6DAC6211ACEDA for ; Mon, 7 Jan 2019 11:22:26 -0800 (PST) Received: by mail-wm1-x343.google.com with SMTP id b11so1921654wmj.1 for ; Mon, 07 Jan 2019 11:22:26 -0800 (PST) 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=sAQVnT/f3y9Kh8eO7KkUh9BqmKc8bL9UoHv5GzPT0Qo=; b=h9iI2LcSCd9p9CLCz+WfGCfppnFev1S5a5DtitK7webMO7dagKC2YYFtxyh5MzBv5C bMLlQSv/HevqbchGE4G6aseYfu69aAR8PFwaQ/3UBkzB8QDXEmWwVG0wy687ifGiihcc Y9FmdYFzNJFKDZTelGAj4J9vlz/7D/p6MAxZY= 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=sAQVnT/f3y9Kh8eO7KkUh9BqmKc8bL9UoHv5GzPT0Qo=; b=qYAylBSVOlllPK+uBLLGSK46dai8f6bhbcXNFq9PiCT1uRgFAcsrjAXMhlga+I1QAA fmf2pibi378qrRxuqEyAe4ZzmZFnlREy8AVb6nBCofXBTt3f+f64frBqiax+vv5zr1JD G9EGddwec7PW8GonaK+3FGcrMIIT0mYPAJ3Ek4Zk0igtRCaWXYcwlFm1rZ+NOgMDBISW wb6yfx66qbE6Hj1zfD/C/5kox7BYG5fLy6fHbmp2SkXZKiYeAEz4PspGt+vEMaW70luj 2d5lBYsPsk9JGi3Pm5R7K3QHiqtsRO2JVovlsqTLkJlWKy6BOyIiBailS0A9iLB1PTpY DUXw== X-Gm-Message-State: AJcUukdsdcbVrWqzkfmrsUANCmQYNeqyfByKqeedHByMunnZ17M8isNw 6N6bjLsbz9MQK2cOAPpolyTwYQ== X-Google-Smtp-Source: ALg8bN4qg4SGLWGl9TRkdxaDpQdSVrqTy3yTsXX8MsVZflEqNYm7GePLIve3pU0YcEZNqd1YJ7aL8g== X-Received: by 2002:a1c:ac42:: with SMTP id v63mr9210469wme.119.1546888943601; Mon, 07 Jan 2019 11:22:23 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id x10sm61488587wrn.29.2019.01.07.11.22.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 07 Jan 2019 11:22:22 -0800 (PST) Date: Mon, 7 Jan 2019 19:22:20 +0000 From: Leif Lindholm To: Laszlo Ersek Cc: AKASHI Takahiro , Alexander Graf , Heinrich Schuchardt , trini@konsulko.com, robdclark@gmail.com, u-boot@lists.denx.de, edk2-devel@lists.01.org, Jian J Wang , Hao Wu , Ruiyu Ni , Star Zeng , Andrew Fish , Michael D Kinney , Ard Biesheuvel Message-ID: <20190107192220.ugkcxfd3betvuypi@bivouac.eciton.net> References: <20181214101043.14067-1-takahiro.akashi@linaro.org> <20181214101043.14067-3-takahiro.akashi@linaro.org> <20181217011626.GC14562@linaro.org> <84b6f3fd-ed68-a541-7727-69e5392984e6@suse.de> <20181225083024.GC14405@linaro.org> <20190107140932.uefkly3a3jzlyjjf@bivouac.eciton.net> <7d6fbbff-ca48-588a-6082-bf8b95a7e829@redhat.com> MIME-Version: 1.0 In-Reply-To: <7d6fbbff-ca48-588a-6082-bf8b95a7e829@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols 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: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 X-List-Received-Date: Mon, 07 Jan 2019 19:22:26 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jan 07, 2019 at 07:29:47PM +0100, Laszlo Ersek wrote: > On 01/07/19 15:09, Leif Lindholm wrote: > > Apologies for late reply, back from holidays today. > > I'm going to snip a whole lot of context below, since I have no idea > what project this is about, and/or what files in that project (no diff > hunk headers in the context). Judged from the address list, is this > about u-boot perhaps? And adding type definitions to u-boot so they > conform to the UEFI spec, and (assuming this "and" is possible) match > edk2 practice? Well, the u-boot UEFI interface is what triggered the questions. And the answer is relevant to the people asking, so I kept the list on cc. But I'm more concerned with regards to whether EDK2 is compliant, and what impacts this has on the spec if not. > > My understanding is this: > > - The EDK2 implementation does not conform to the specification; it > > completely packs the EFI_HII_KEYBOARD_LAYOUT, which the > > specification does not mention anything about. Since this code is > > well in the wild, and drivers tested against the current layout need > > to continuw eorking, I expect the only possible solution is to > > update the specification to say EFI_HII_KEYBOARD_LAYOUT must be > > packed. > > I'm going to take a pass on this. :) Be my guest :) > > - The default EDK2 definition of GUID (and hence EFI_GUID) gives it a > > 32-bit alignment requirement also on 64-bit architectures. In > > practice, I expect this would only affect (some of the) GUIDs that > > are members of structs used in UEFI interfaces. But that may already > > be too common an occurrence to audit and address in EDK2. Does the > > spec need to change on this also? > > The UEFI spec (v2.7) explicitly requires EFI_GUID to be 64-bit aligned, > unless specified otherwise. See in "Table 5. Common UEFI Data Types": > > EFI_GUID -- 128-bit buffer containing a unique identifier value. > Unless otherwise specified, aligned on a 64-bit > boundary. Indeed. > Whether edk2 satisfies that, and if so, how (by chance / by general > build flags), I don't know. The code says, > > /// > /// 128 bit buffer containing a unique identifier value. > /// Unless otherwise specified, aligned on a 64 bit boundary. > /// > typedef struct { > UINT32 Data1; > UINT16 Data2; > UINT16 Data3; > UINT8 Data4[8]; > } GUID; > > I think there may have been an expectation in "MdePkg/Include/Base.h" > that the supported compilers would automatically ensure the specified > alignment, given the structure definition. But that would be expecting things not only not guaranteed by C, but something there is no semantic information suggesting would be useful for the compiler to do above. C is quite explicit that the above would be given a 32-bit alignment requirement. The most aligned member is Data1, and its alignment is 32 bits. Now, technically, it would be absolutely fine for this struct to be 32-but aligned, if the EFI_GUID typedef in MdePkg/Include/Uefi/UefiBaseType.h added this constraint. It does not. / Leif