linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: linux-efi@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	linux-kernel@vger.kernel.org,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Alexander Graf <agraf@suse.de>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Borislav Petkov <bp@alien8.de>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Jeffrey Hugo <jhugo@codeaurora.org>,
	Lee Jones <lee.jones@linaro.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Jones <pjones@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Subject: [PATCH 04/10] efi: use 32-bit alignment for efi_guid_t
Date: Sat,  2 Feb 2019 10:41:13 +0100	[thread overview]
Message-ID: <20190202094119.13230-5-ard.biesheuvel@linaro.org> (raw)
In-Reply-To: <20190202094119.13230-1-ard.biesheuvel@linaro.org>

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 <xypron.glpk@gmx.de>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 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)
-- 
2.17.1

  parent reply	other threads:[~2019-02-02  9:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-02  9:41 [GIT PULL 00/10] EFI changes for v5.1 Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 01/10] x86/efi: Mark can_free_region() as an __init function Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 02/10] x86/efi: Return error status if mapping EFI regions fail Ard Biesheuvel
2019-02-04  7:18   ` Ingo Molnar
2019-02-04  7:25     ` Ingo Molnar
2019-02-04  7:28     ` Ard Biesheuvel
2019-02-04 22:29       ` Prakhya, Sai Praneeth
2019-02-08 15:50         ` Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 03/10] efi: memattr: don't bail on zero VA if it equals the region's PA Ard Biesheuvel
2019-02-02  9:41 ` Ard Biesheuvel [this message]
2019-02-02  9:41 ` [PATCH 05/10] efi/fdt: More cleanups Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 06/10] efi: replace GPL license boilerplate with SPDX headers Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 07/10] efi: arm/arm64: allow SetVirtualAddressMap() to be omitted Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 08/10] x86: make ARCH_USE_MEMREMAP_PROT a generic Kconfig symbol Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 09/10] efi: x86: convert x86 EFI earlyprintk into generic earlycon implementation Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 10/10] acpi: bgrt: parse BGRT to obtain BMP address before it gets clobbered Ard Biesheuvel
2019-02-05 19:07   ` Ghannam, Yazen
2019-02-05 23:27     ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190202094119.13230-5-ard.biesheuvel@linaro.org \
    --to=ard.biesheuvel@linaro.org \
    --cc=agraf@suse.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=bp@alien8.de \
    --cc=jhugo@codeaurora.org \
    --cc=lee.jones@linaro.org \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pjones@redhat.com \
    --cc=sai.praneeth.prakhya@intel.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).