Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp3613103ima; Mon, 4 Feb 2019 02:06:40 -0800 (PST) X-Google-Smtp-Source: AHgI3IbW4OftyBmX8jMoesVbddLP41PKzBDS3+J3QnDNSvIEu6UUF7ZshqBKDhyX0T9ywcMHtTpB X-Received: by 2002:a63:ed03:: with SMTP id d3mr12256859pgi.275.1549274800040; Mon, 04 Feb 2019 02:06:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549274799; cv=none; d=google.com; s=arc-20160816; b=M+4tq7nqvAlRkld8MGJJdZfPVGhbKutZDjSmE8CmfkIvDJ6XRgUcK++JB6hEmS05Cv AkGooJSLJsZFszvyqD4n8KNW9il/OnJJtX2IUpKQCni0aS40wE0uQLyTtLWMV5YpG830 wZ9ZdsdF7kiuOFU11DJ94cNThoo7+YDqjF+6BPntS/F0hLA5TMJc1qbV6Kj2aAYGwFDn JDR5p4T0HvuiQE4ebxyCZ+vWmDoSPWxh+o+2NtCqoZ5hv/8+DTzASwX+yHuQ/uIr0PNk wHixow0miz0jDQWBtjlBtv08/knREuHH4g8BBP4H3Aup52X0A98bOF7J+k9d1tl3geve D0Nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition :content-transfer-encoding:mime-version:robot-unsubscribe:robot-id :git-commit-id:subject:to:references:in-reply-to:reply-to:cc :message-id:from:date; bh=HR3jnPKNVP2mp9NebjCSVcOprX2XcuJHTw75vQNP8Uo=; b=I6r+Yq6+VY1TR7zdYqouw8K/iNPmbSAOVckCxwu5o8LbypU3009sEhFVYb5+Hd0cxK uqSFwD85zbFAauG4resYGMHmwu6LtkzwVie08Mpnft7+NDLzku2OkcaDpnrQLXsDBQzI 6eOcaksZn/ofWEpKCxQmEUDB8XHF8hWLazZSiUox8EDIXxVCYPcUGYJmYRiweKoMRMwc yGdwyVyt34BDGaZO/PHWFLNMqPrIc5WngeyywnxdHNFnx76DjLKRisVK17G+v7Cy1j/c ogHSW8gKeNyMzysSZZt/0rkScHEtTluKRd6dPU3+EAZbQp4gI5mwUMrUgRv3Cy0MiNXy xYDQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e67si8031610pfa.15.2019.02.04.02.06.23; Mon, 04 Feb 2019 02:06:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728223AbfBDJoE (ORCPT + 99 others); Mon, 4 Feb 2019 04:44:04 -0500 Received: from terminus.zytor.com ([198.137.202.136]:37457 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725889AbfBDJoE (ORCPT ); Mon, 4 Feb 2019 04:44:04 -0500 Received: from terminus.zytor.com (localhost [127.0.0.1]) by terminus.zytor.com (8.15.2/8.15.2) with ESMTPS id x148hdvF354514 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 4 Feb 2019 00:43:39 -0800 Received: (from tipbot@localhost) by terminus.zytor.com (8.15.2/8.15.2/Submit) id x148hdu5354511; Mon, 4 Feb 2019 00:43:39 -0800 Date: Mon, 4 Feb 2019 00:43:39 -0800 X-Authentication-Warning: terminus.zytor.com: tipbot set sender to tipbot@zytor.com using -f From: tip-bot for Ard Biesheuvel Message-ID: Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, pjones@redhat.com, ard.biesheuvel@linaro.org, bjorn.andersson@linaro.org, peterz@infradead.org, matt@codeblueprint.co.uk, torvalds@linux-foundation.org, tglx@linutronix.de, sai.praneeth.prakhya@intel.com, xypron.glpk@gmx.de, bp@alien8.de, leif.lindholm@linaro.org, lee.jones@linaro.org, agraf@suse.de, hpa@zytor.com, jhugo@codeaurora.org, takahiro.akashi@linaro.org Reply-To: tglx@linutronix.de, torvalds@linux-foundation.org, xypron.glpk@gmx.de, sai.praneeth.prakhya@intel.com, bp@alien8.de, hpa@zytor.com, agraf@suse.de, lee.jones@linaro.org, leif.lindholm@linaro.org, jhugo@codeaurora.org, takahiro.akashi@linaro.org, linux-kernel@vger.kernel.org, mingo@kernel.org, pjones@redhat.com, ard.biesheuvel@linaro.org, peterz@infradead.org, matt@codeblueprint.co.uk, bjorn.andersson@linaro.org In-Reply-To: <20190202094119.13230-5-ard.biesheuvel@linaro.org> References: <20190202094119.13230-5-ard.biesheuvel@linaro.org> To: linux-tip-commits@vger.kernel.org Subject: [tip:efi/core] efi: Use 32-bit alignment for efi_guid_t Git-Commit-ID: 494c704f9af0a0cddf593b381ea44320888733e6 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline X-Spam-Status: No, score=-0.8 required=5.0 tests=ALL_TRUSTED,BAYES_00, FREEMAIL_FORGED_REPLYTO,T_DATE_IN_FUTURE_96_Q autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on terminus.zytor.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 494c704f9af0a0cddf593b381ea44320888733e6 Gitweb: https://git.kernel.org/tip/494c704f9af0a0cddf593b381ea44320888733e6 Author: Ard Biesheuvel AuthorDate: Sat, 2 Feb 2019 10:41:13 +0100 Committer: Ingo Molnar CommitDate: Mon, 4 Feb 2019 08:26:35 +0100 efi: Use 32-bit alignment for 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. Reported-by: Heinrich Schuchardt Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm Cc: AKASHI Takahiro Cc: Alexander Graf Cc: Bjorn Andersson Cc: Borislav Petkov Cc: Jeffrey Hugo Cc: Lee Jones Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Jones Cc: Peter Zijlstra Cc: Sai Praneeth Prakhya Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20190202094119.13230-5-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar --- 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)