From patchwork Tue Jan 8 15:28:29 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 10752253 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 8E0D36C5 for ; Tue, 8 Jan 2019 15:28:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7BD2A28D2C for ; Tue, 8 Jan 2019 15:28:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6F09E28D35; Tue, 8 Jan 2019 15:28:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 081EB28D2C for ; Tue, 8 Jan 2019 15:28:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:To :From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=It6OfEYxh0d4VbUmxLKLEQistajE6y6J6dnhwptd+Yc=; b=OYN+3NZBYcWORW A3+a+3TjRGbr4EcnhTKCtRbCsRJIv9ZmIkroqBrqu/fhlGl53DaGUPgodgYyZr8Nc+QLEyCDRjf7G szJn230PA5KaI9mvalbF6BJczICmwqmGw1vIzNt4bqy2XEma9B5xpM9o7mEE1JqVcOCOsdL3V81Uy WH8r/KyUFBS6bnzq54wDChxZ9oU7E8LJWswwvrE3BMZkXsc3Fk0eIG95JjXhEYUuuOwjxzbX9bnSl XuCLyNb4CUE6+1nmylb0iGKY9HwzANbIv85fOHauQ1pOJz4nXK6eLC7VY2PWis93gxEtBv1BvKOBr FWvfq39JK8J2s1TZybsA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1ggtJ3-0006aJ-C0; Tue, 08 Jan 2019 15:28:41 +0000 Received: from mail-ed1-x544.google.com ([2a00:1450:4864:20::544]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1ggtJ0-0006Zn-9O for linux-arm-kernel@lists.infradead.org; Tue, 08 Jan 2019 15:28:39 +0000 Received: by mail-ed1-x544.google.com with SMTP id h15so4621420edb.4 for ; Tue, 08 Jan 2019 07:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=4K6IrfJGLuqOXV0rX4sdp3u8fI3xqpWy1jqXH78SKIU=; b=HTr1FAIfKdIpzMCSqSHifDPKvfZQ5ijKIqyxAnzCi6g+18bJJRAYJuSaxfi0gCcH4j RBOPMO/39tjOYjMTrkw23K7iszPzbSV44PnfbAewgf89PWnO2woiZ9lFTs0ZsbAjpo0K AoB0adGfIfHS546s3DhS1X4e8Apo0TCdZdKHg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=4K6IrfJGLuqOXV0rX4sdp3u8fI3xqpWy1jqXH78SKIU=; b=IfdzEtrY6xW7rXPPcwFybdd4zAocC2MnIehE5lyYLJ9fR15Sm/s7mTo/Ae+09F50jq RkLod+EyLw34hbu1Pgvcw5P0D0QYDSc8Iwta1iXCN3SVOUFCcSiXgdO8t6lZv5QjAjep Kpm5spsneICMougCjN2d4KLDgKqFU5kXD7zxO+idyWVmc1ICPr8/suwrlEUOkHZkFei/ 3o0VZW5VIAkH5hKlHgvglLML6yXtvpU0oOJxAWSYY0biRKpfQ6bq91Vlw6nTubKjXirs 1FJBUAFcuLzErJpLocxlueNTSAUrizXU8SfaYwAT7Us02Y6Ielw8HjOybXWjwPruY8w9 hStg== X-Gm-Message-State: AJcUukcFBnQIc9BfCL8+i1ZFHmuD97LQNnvVQg9yzfBiDA/WlwTSm4N1 CQJugoO2WoirNe+eXaCxJ9vSHA== X-Google-Smtp-Source: ALg8bN7lsSRempJZTBNRWcnOR1FM2UfPRGxKEqGRxAcuFv/MbR66pL1icSrLU/ho7bOsU2q96l/QBw== X-Received: by 2002:a17:906:1189:: with SMTP id n9-v6mr2216625eja.2.1546961315691; Tue, 08 Jan 2019 07:28:35 -0800 (PST) Received: from localhost.localdomain (laubervilliers-657-1-83-120.w92-154.abo.wanadoo.fr. [92.154.90.120]) by smtp.gmail.com with ESMTPSA id m44sm65715edm.54.2019.01.08.07.28.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Jan 2019 07:28:34 -0800 (PST) From: Ard Biesheuvel To: linux-efi@vger.kernel.org Subject: [PATCH] efi: use 32-bit alignment for efi_guid_t Date: Tue, 8 Jan 2019 16:28:29 +0100 Message-Id: <20190108152829.11579-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190108_072838_332346_F8FF3A9D X-CRM114-Status: GOOD ( 11.90 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ard Biesheuvel , Heinrich Schuchardt , leif.lindholm@linaro.org, lersek@redhat.com, mingo@kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP The UEFI spec and EDK2 reference implementation both define EFI_GUID as struct { u32 a; u16; b; u16 c; u8 d[8]; }; and so the implied alignment is 32 bits not 8 bits like our guid_t. In some cases (i.e., on 32-bit ARM), this means that firmware services invoked by the kernel may assume that efi_guid_t* arguments are 32-bit aligned, and use memory accessors that do not tolerate misalignment. So let's set the minimum alignment to 32 bits. Note that the UEFI spec as well as some comments in the EDK2 code base suggest that EFI_GUID should be 64-bit aligned, but this appears to be a mistake, given that no code seems to exist that actually enforces that or relies on it. Reported-by: Heinrich Schuchardt , Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm --- include/linux/efi.h | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/include/linux/efi.h b/include/linux/efi.h index 45ff763fba76..be08518c2553 100644 --- a/include/linux/efi.h +++ b/include/linux/efi.h @@ -48,7 +48,20 @@ typedef u16 efi_char16_t; /* UNICODE character */ typedef u64 efi_physical_addr_t; typedef void *efi_handle_t; -typedef guid_t efi_guid_t; +/* + * The UEFI spec and EDK2 reference implementation both define EFI_GUID as + * struct { u32 a; u16; b; u16 c; u8 d[8]; }; and so the implied alignment + * is 32 bits not 8 bits like our guid_t. In some cases (i.e., on 32-bit ARM), + * this means that firmware services invoked by the kernel may assume that + * efi_guid_t* arguments are 32-bit aligned, and use memory accessors that + * do not tolerate misalignment. So let's set the minimum alignment to 32 bits. + * + * Note that the UEFI spec as well as some comments in the EDK2 code base + * suggest that EFI_GUID should be 64-bit aligned, but this appears to be + * a mistake, given that no code seems to exist that actually enforces that + * or relies on it. + */ +typedef guid_t efi_guid_t __aligned(__alignof__(u32)); #define EFI_GUID(a,b,c,d0,d1,d2,d3,d4,d5,d6,d7) \ GUID_INIT(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)