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::141; helo=mail-it1-x141.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x141.google.com (mail-it1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (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 CC21F21198CC4 for ; Tue, 8 Jan 2019 02:07:39 -0800 (PST) Received: by mail-it1-x141.google.com with SMTP id m62so5435715ith.5 for ; Tue, 08 Jan 2019 02:07:39 -0800 (PST) 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=wIkdE/AvTHfBnSHrSp837cqN/Y37Pymt1Gf3CmXYRBg=; b=BRtKeHo5E8aC9qxExTFcN8g7W5xLx3jSJcv15ga5vmN/uLOOkkbET0eJEtUVaqC7+L +eehScIQcpMcuPUuzHNp385x330ruRIh2+RbOjuNLgnErHtNLEYyBUgZmpgmDrKJZJv4 9ncRYiygC67UuYRaoQiUJ9LU7HaTadSfUVWGE= 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=wIkdE/AvTHfBnSHrSp837cqN/Y37Pymt1Gf3CmXYRBg=; b=sux+IvzCHLdbxsuhfl5Bv0SUaU0Mk/6GksIejwCJlHibMMLn272RyfoaEqrGiiQjeY yUx3BezT1TEeO+Dsb2YGiKHdx0F1gxgjuHID5Asrj3UU01fWc1JxbNnWKnvVD8c9xyej SS4hIwC+Knb5QWwr56P4qTMY+QYnc66PMxQQ3XObaRuNrC5LU4kVKdjS00CPlXhkvKeS JFkyuWw5CMk/bAPnaOSeipR8B4QayCoAjNGjykyYuQ6fDFce+toSmWCSYvmqU9i5D87e hgikfAPUfoSp/XK5crveU26jbxQi49vFrYgEbUTn9T4rGkPkYD7TaV6kdO2MWrLbJSJQ 8/Hg== X-Gm-Message-State: AJcUukfyZHFZ9XL5NOE4QjuKcWcPXouBiDpUNwLo6diI1eZrhoKXt6dl 4gbyE8Nvzu1L8lt/20DM8VOdGKu81nc9KtYCNNqnfg== X-Google-Smtp-Source: ALg8bN6JulgDDKdeZbPn7vRlzcgVulqayvGdaiwsFddhnMkR+Vvg7TJAH2rnWcmmvr6ZMGTbTJEuWviu/+zs2S+ZuxA= X-Received: by 2002:a24:710:: with SMTP id f16mr742703itf.121.1546942058895; Tue, 08 Jan 2019 02:07:38 -0800 (PST) MIME-Version: 1.0 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> <20190107192220.ugkcxfd3betvuypi@bivouac.eciton.net> <1d1c1e2f-193c-5e1f-f51a-b922b67eb428@redhat.com> <20190108095102.myetfzaancuzq7cx@bivouac.eciton.net> In-Reply-To: <20190108095102.myetfzaancuzq7cx@bivouac.eciton.net> From: Ard Biesheuvel Date: Tue, 8 Jan 2019 11:07:27 +0100 Message-ID: To: Leif Lindholm Cc: Laszlo Ersek , AKASHI Takahiro , Alexander Graf , Heinrich Schuchardt , Tom Rini , Rob Clark , U-Boot Mailing List , "edk2-devel@lists.01.org" , Jian J Wang , Hao Wu , Ruiyu Ni , Star Zeng , Andrew Fish , Michael D Kinney , Liming Gao 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: Tue, 08 Jan 2019 10:07:40 -0000 Content-Type: text/plain; charset="UTF-8" On Tue, 8 Jan 2019 at 10:51, Leif Lindholm wrote: > > MdePkg/MdeModulePkg maintainers - any comments? > > On Tue, Jan 08, 2019 at 01:28:00AM +0100, Laszlo Ersek wrote: > > On 01/07/19 20:22, Leif Lindholm wrote: > > > On Mon, Jan 07, 2019 at 07:29:47PM +0100, Laszlo Ersek wrote: > > > > >> 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. [...] > > > > Agreed. I'm not saying the edk2 code is right, just guessing why the > > code might look like it does. This would not be the first silent > > assumption, I think. > > > > Anyhow, I think it would be better to change the code than the spec. > > Of course it would be better to change the code than the spec. > > But as Ard points out off-thread, doing (as a hack, with gcc) > > diff --git a/MdePkg/Include/Uefi/UefiBaseType.h > b/MdePkg/Include/Uefi/UefiBaseType.h > index 8c9d571eb1..75409f3460 100644 > --- a/MdePkg/Include/Uefi/UefiBaseType.h > +++ b/MdePkg/Include/Uefi/UefiBaseType.h > @@ -26,7 +26,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, > EITHER EXPRESS OR IMPLIED. > /// > /// 128-bit buffer containing a unique identifier value. > /// > -typedef GUID EFI_GUID; > +typedef GUID EFI_GUID __attribute__((aligned (8))); > /// > /// Function return status for EFI API. > /// > > breaks Linux boot on ARM (32-bit), since it inserts 32-bits of padding > between ConfigurationTable entries in the system table. So I don't see > how that can realistically be fixed in the EDK2 codebase. > > And with things like the EFI_HII_KEYBOARD_LAYOUT struct, if there has > ever been compatibility between EDK2 and commercial BIOSes, then that > struct has always been treated as packed (not just 32-bit aligned > GUIDs), and the spec just needs to reflect reality. If there hasn't, > then indeed the code change here would be trivial. > > (Adding Liming as well, since we're now discussing MdePkg also.) > > Yes, this discussion belongs on USWG (UEFI specification working group > mailing list), but I want to hear some comment from the package > maintainers first. > Since we don't align EFI_GUIDs to 64 bits anywhere in the EDK2 code base, and given that it is always possible to relax a spec but not to tighten it without breaking backward compatibility, I think the only sane way to deal with this is to update the spec and/or any pertinent comments in the code to say that EFI_GUIDs are 32-bit aligned not 64-bit aligned. That still leaves us with an issue in Linux, since efi_guid_t there has no minimal alignment, and runtime services code taking EFI_GUID pointers as input (such as Get/SetVariable) may assume they are 32-bit aligned (given the UINT32 member in the EDK2 definition) and thus assume it is safe to use load double/multiple instructions to access them (which will either fault or cause an alignment fixup to trigger if they are invoked with an unaligned memory address). But this is a different issue.