[PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks

[PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks

[Ard Biesheuvel]

I merged two EFI/ARM related series, whose v1's I sent out last week:

Changes since v1:
- added various tags from various people
- new patch #3 to undefine __init

@Matt: are you happy with all of this going through the arm64 tree? I don't
think it clashes with anything else we've got queued up for v4.6 in tip/efi/core

Series 1: arm efi minor fixes
http://thread.gmane.org/gmane.linux.ports.arm.kernel/473027
This fixes two minor issues with the handling of .init data in the stub (#1, #2)

Patch #3 is a new patch that un-#defines __init in efistub.h, to catch its
inadvertent use in the UEFI stub

Patch #4 replaces some instances of early_memremap() with early_memremap_ro()
where the region in question is only accessed in r/o mode.

Series 2: UEFI stub pre-boot compat checks
http://thread.gmane.org/gmane.linux.ports.arm.kernel/473189

As discussed earlier today [1], and last year [2], it makes sense for the
UEFI stub to perform some basic checks on the hardware for missing features
that would prevent the kernel from booting to a state where it can even
complain about this.

So implements this for ARM, to check on LPAE builds whether the CPU supports
it (patch #5), and for arm64, to check whether the build time granule is
implemented by the CPU (patch #6). Patch #7 wires it up into the shared init
code.

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/472880
[2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/447370

Ard Biesheuvel (7):
  arm64: efistub: drop __init annotation from handle_kernel_image()
  arm64: vmlinux.lds.S: handle .init.rodata.xxx and .init.bss sections
  efi: efistub: prevent __init annotations from being used
  efi: arm-init: use read-only early mappings
  ARM: efistub: check for LPAE support before booting a LPAE kernel
  arm64: efistub: check for h/w support before booting a >4 KB granule
    kernel
  ARM/arm64: efistub: perform hardware compatibility check

 arch/arm64/kernel/vmlinux.lds.S           |  1 +
 drivers/firmware/efi/arm-init.c           | 14 ++++----
 drivers/firmware/efi/libstub/arm-stub.c   |  4 +++
 drivers/firmware/efi/libstub/arm32-stub.c | 17 ++++++++++
 drivers/firmware/efi/libstub/arm64-stub.c | 34 ++++++++++++++++----
 drivers/firmware/efi/libstub/efistub.h    | 12 +++++++
 6 files changed, 68 insertions(+), 14 deletions(-)

-- 
2.5.0

[PATCH v2 1/7] arm64: efistub: drop __init annotation from handle_kernel_image()

[Ard Biesheuvel]

After moving arm64-stub.c to libstub/, all of its sections are emitted
as .init.xxx sections automatically, and the __init annotation of
handle_kernel_image() causes it to end up in .init.init.text, which is
not recognized as an __init section by the linker scripts. So drop the
annotation.

Acked-by: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Acked-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Tested-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/firmware/efi/libstub/arm64-stub.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
index 78dfbd34b6bf..9e0342745e4f 100644
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -13,13 +13,13 @@
 #include <asm/efi.h>
 #include <asm/sections.h>
 
-efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table_arg,
-					unsigned long *image_addr,
-					unsigned long *image_size,
-					unsigned long *reserve_addr,
-					unsigned long *reserve_size,
-					unsigned long dram_base,
-					efi_loaded_image_t *image)
+efi_status_t handle_kernel_image(efi_system_table_t *sys_table_arg,
+				 unsigned long *image_addr,
+				 unsigned long *image_size,
+				 unsigned long *reserve_addr,
+				 unsigned long *reserve_size,
+				 unsigned long dram_base,
+				 efi_loaded_image_t *image)
 {
 	efi_status_t status;
 	unsigned long kernel_size, kernel_memsize = 0;
-- 
2.5.0

[PATCH v2 2/7] arm64: vmlinux.lds.S: handle .init.rodata.xxx and .init.bss sections

[Ard Biesheuvel]

The EFI stub is typically built into the decompressor (x86, ARM) so none
of its symbols are annotated as __init. However, on arm64, the stub is
linked into the kernel proper, and the code is __init annotated at the
section level by prepending all names of SHF_ALLOC sections with '.init'.

This results in section names like .init.rodata.str1.8 (for string literals)
and .init.bss (which is tiny), both of which can be moved into the .init.data
output section.

Acked-by: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Acked-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Tested-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Reviewed-by: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 arch/arm64/kernel/vmlinux.lds.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index e3928f578891..cbf4db440e9c 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -134,6 +134,7 @@ SECTIONS
 		CON_INITCALL
 		SECURITY_INITCALL
 		INIT_RAM_FS
+		*(.init.rodata.* .init.bss)	/* from the EFI stub */
 	}
 	.exit.data : {
 		ARM_EXIT_KEEP(EXIT_DATA)
-- 
2.5.0

[PATCH v2 3/7] efi: efistub: prevent __init annotations from being used

[Ard Biesheuvel]

__init annotations should not be used in the EFI stub, since the code is
either included in the decompressor (x86, ARM) where they have no effect,
or the whole stub is __init annotated at the section level (arm64), by
renaming the sections, in which case the __init annotations will be
redundant, and will result in section names like .init.init.text, and our
linker script does not expect that. So un-#define __init so that its
inadvertent use will force a build error.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/firmware/efi/libstub/efistub.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 6b6548fda089..275f395c886d 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -5,6 +5,16 @@
 /* error code which can't be mistaken for valid address */
 #define EFI_ERROR	(~0UL)
 
+/*
+ * __init annotations should not be used in the EFI stub, since the code is
+ * either included in the decompressor (x86, ARM) where they have no effect,
+ * or the whole stub is __init annotated at the section level (arm64), by
+ * renaming the sections, in which case the __init annotation will be
+ * redundant, and will result in section names like .init.init.text, and our
+ * linker script does not expect that.
+ */
+#undef __init
+
 void efi_char16_printk(efi_system_table_t *, efi_char16_t *);
 
 efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg, void *__image,
-- 
2.5.0

[PATCH v2 4/7] efi: arm-init: use read-only early mappings

[Ard Biesheuvel]

The early mappings of the EFI system table contents and the UEFI memory
map are read-only from the OS point of view. So map them read-only to
protect them from inadvertent modification.

Acked-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Tested-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/firmware/efi/arm-init.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d571b53c..aa1f743152a2 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -61,8 +61,8 @@ static int __init uefi_init(void)
 	char vendor[100] = "unknown";
 	int i, retval;
 
-	efi.systab = early_memremap(efi_system_table,
-				    sizeof(efi_system_table_t));
+	efi.systab = early_memremap_ro(efi_system_table,
+				       sizeof(efi_system_table_t));
 	if (efi.systab == NULL) {
 		pr_warn("Unable to map EFI system table.\n");
 		return -ENOMEM;
@@ -86,8 +86,8 @@ static int __init uefi_init(void)
 			efi.systab->hdr.revision & 0xffff);
 
 	/* Show what we know for posterity */
-	c16 = early_memremap(efi_to_phys(efi.systab->fw_vendor),
-			     sizeof(vendor) * sizeof(efi_char16_t));
+	c16 = early_memremap_ro(efi_to_phys(efi.systab->fw_vendor),
+				sizeof(vendor) * sizeof(efi_char16_t));
 	if (c16) {
 		for (i = 0; i < (int) sizeof(vendor) - 1 && *c16; ++i)
 			vendor[i] = c16[i];
@@ -100,8 +100,8 @@ static int __init uefi_init(void)
 		efi.systab->hdr.revision & 0xffff, vendor);
 
 	table_size = sizeof(efi_config_table_64_t) * efi.systab->nr_tables;
-	config_tables = early_memremap(efi_to_phys(efi.systab->tables),
-				       table_size);
+	config_tables = early_memremap_ro(efi_to_phys(efi.systab->tables),
+					  table_size);
 	if (config_tables == NULL) {
 		pr_warn("Unable to map EFI config table array.\n");
 		retval = -ENOMEM;
@@ -185,7 +185,7 @@ void __init efi_init(void)
 	efi_system_table = params.system_table;
 
 	memmap.phys_map = params.mmap;
-	memmap.map = early_memremap(params.mmap, params.mmap_size);
+	memmap.map = early_memremap_ro(params.mmap, params.mmap_size);
 	if (memmap.map == NULL) {
 		/*
 		* If we are booting via UEFI, the UEFI memory map is the only
-- 
2.5.0

[PATCH v2 5/7] ARM: efistub: check for LPAE support before booting a LPAE kernel

[Ard Biesheuvel]

A kernel built with support for LPAE cannot boot to a state where it
can inform the user about it if it fails due to missing LPAE support
in the hardware.

If we happen to be booting via UEFI, we can fail gracefully so check
for LPAE support in the hardware on CONFIG_ARM_LPAE builds before
entering the kernel proper.

Reviewed-by: Jeremy Linton <jeremy.linton-5wv7dgnIgG8@public.gmane.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/firmware/efi/libstub/arm32-stub.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/firmware/efi/libstub/arm32-stub.c b/drivers/firmware/efi/libstub/arm32-stub.c
index 495ebd657e38..6f42be4d0084 100644
--- a/drivers/firmware/efi/libstub/arm32-stub.c
+++ b/drivers/firmware/efi/libstub/arm32-stub.c
@@ -9,6 +9,23 @@
 #include <linux/efi.h>
 #include <asm/efi.h>
 
+efi_status_t check_platform_features(efi_system_table_t *sys_table_arg)
+{
+	int block;
+
+	/* non-LPAE kernels can run anywhere */
+	if (!IS_ENABLED(CONFIG_ARM_LPAE))
+		return EFI_SUCCESS;
+
+	/* LPAE kernels need compatible hardware */
+	block = cpuid_feature_extract(CPUID_EXT_MMFR0, 0);
+	if (block < 5) {
+		pr_efi_err(sys_table_arg, "This LPAE kernel is not supported by your CPU\n");
+		return EFI_UNSUPPORTED;
+	}
+	return EFI_SUCCESS;
+}
+
 efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
 				 unsigned long *image_addr,
 				 unsigned long *image_size,
-- 
2.5.0

[PATCH v2 6/7] arm64: efistub: check for h/w support before booting a >4 KB granule kernel

[Ard Biesheuvel]

A kernel built with support for a page size that is not supported by the
hardware it runs on cannot boot to a state where it can inform the user
about it.

If we happen to be booting via UEFI, we can fail gracefully so check
if the currently configured page size is supported by the hardware before
entering the kernel proper. Note that UEFI mandates support for 4 KB pages,
so in that case, no check is needed.

Reviewed-by: Jeremy Linton <jeremy.linton-5wv7dgnIgG8@public.gmane.org>
Tested-by: Suzuki K Poulose <suzuki.poulose-5wv7dgnIgG8@public.gmane.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/firmware/efi/libstub/arm64-stub.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
index 9e0342745e4f..aef04ad60e0d 100644
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -12,6 +12,26 @@
 #include <linux/efi.h>
 #include <asm/efi.h>
 #include <asm/sections.h>
+#include <asm/sysreg.h>
+
+efi_status_t check_platform_features(efi_system_table_t *sys_table_arg)
+{
+	u64 tg;
+
+	/* UEFI mandates support for 4 KB granule, no need to check */
+	if (IS_ENABLED(CONFIG_ARM64_4K_PAGES))
+		return EFI_SUCCESS;
+
+	tg = (read_cpuid(ID_AA64MMFR0_EL1) >> ID_AA64MMFR0_TGRAN_SHIFT) & 0xf;
+	if (tg != ID_AA64MMFR0_TGRAN_SUPPORTED) {
+		if (IS_ENABLED(CONFIG_ARM64_64K_PAGES))
+			pr_efi_err(sys_table_arg, "This 64 KB granule kernel is not supported by your CPU\n");
+		else
+			pr_efi_err(sys_table_arg, "This 16 KB granule kernel is not supported by your CPU\n");
+		return EFI_UNSUPPORTED;
+	}
+	return EFI_SUCCESS;
+}
 
 efi_status_t handle_kernel_image(efi_system_table_t *sys_table_arg,
 				 unsigned long *image_addr,
-- 
2.5.0

[PATCH v2 7/7] ARM/arm64: efistub: perform hardware compatibility check

[Ard Biesheuvel]

Before proceeding with relocating the kernel and parsing the command line,
insert a call to check_platform_features() to allow an arch specific check
to be performed whether the current kernel can execute on the current
hardware.

Reviewed-by: Jeremy Linton <jeremy.linton-5wv7dgnIgG8@public.gmane.org>
Tested-by: Suzuki K Poulose <suzuki.poulose-5wv7dgnIgG8@public.gmane.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/firmware/efi/libstub/arm-stub.c | 4 ++++
 drivers/firmware/efi/libstub/efistub.h  | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index 3397902e4040..6086a874fa3c 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -190,6 +190,10 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
 
 	pr_efi(sys_table, "Booting Linux Kernel...\n");
 
+	status = check_platform_features(sys_table);
+	if (status != EFI_SUCCESS)
+		goto fail;
+
 	/*
 	 * Get a handle to the loaded image protocol.  This is used to get
 	 * information about the running image, such as size and the command
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 275f395c886d..a25ac4c7955f 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -53,4 +53,6 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
 		     unsigned long desc_size, efi_memory_desc_t *runtime_map,
 		     int *count);
 
+efi_status_t check_platform_features(efi_system_table_t *sys_table_arg);
+
 #endif
-- 
2.5.0

Re: [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks

[Mark Rutland]

On Thu, Feb 04, 2016 at 04:50:23PM +0100, Ard Biesheuvel wrote:
> Ard Biesheuvel (7):
>   arm64: efistub: drop __init annotation from handle_kernel_image()
>   arm64: vmlinux.lds.S: handle .init.rodata.xxx and .init.bss sections
>   efi: efistub: prevent __init annotations from being used
>   efi: arm-init: use read-only early mappings
>   ARM: efistub: check for LPAE support before booting a LPAE kernel
>   arm64: efistub: check for h/w support before booting a >4 KB granule
>     kernel
>   ARM/arm64: efistub: perform hardware compatibility check

This all looks good to be, so FWIW, for the series:

Acked-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>

Mark.

Re: [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks

[Matt Fleming]

On Thu, 04 Feb, at 04:50:23PM, Ard Biesheuvel wrote:
> I merged two EFI/ARM related series, whose v1's I sent out last week:
> 
> Changes since v1:
> - added various tags from various people
> - new patch #3 to undefine __init
> 
> @Matt: are you happy with all of this going through the arm64 tree? I don't
> think it clashes with anything else we've got queued up for v4.6 in tip/efi/core

How come this is going through the arm64 tree? Are there other patch
series that this depends on or that depend on it?

If it makes the most sense to take it through that tree, then I'm fine
with it but I'd like to hear a rationale.

Re: [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks

[Ard Biesheuvel]

On 11 February 2016 at 17:16, Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:
> On Thu, 04 Feb, at 04:50:23PM, Ard Biesheuvel wrote:
>> I merged two EFI/ARM related series, whose v1's I sent out last week:
>>
>> Changes since v1:
>> - added various tags from various people
>> - new patch #3 to undefine __init
>>
>> @Matt: are you happy with all of this going through the arm64 tree? I don't
>> think it clashes with anything else we've got queued up for v4.6 in tip/efi/core
>
> How come this is going through the arm64 tree? Are there other patch
> series that this depends on or that depend on it?
>
> If it makes the most sense to take it through that tree, then I'm fine
> with it but I'd like to hear a rationale.

I simply thought it would be most convenient, since it touches
ARM-specific files only. But if you feel it should go via the EFI tree
instead, that is also fine by me.

Thanks,
Ard.

Re: [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks

[Matt Fleming]

On Thu, 11 Feb, at 05:18:12PM, Ard Biesheuvel wrote:
> On 11 February 2016 at 17:16, Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:
> > On Thu, 04 Feb, at 04:50:23PM, Ard Biesheuvel wrote:
> >> I merged two EFI/ARM related series, whose v1's I sent out last week:
> >>
> >> Changes since v1:
> >> - added various tags from various people
> >> - new patch #3 to undefine __init
> >>
> >> @Matt: are you happy with all of this going through the arm64 tree? I don't
> >> think it clashes with anything else we've got queued up for v4.6 in tip/efi/core
> >
> > How come this is going through the arm64 tree? Are there other patch
> > series that this depends on or that depend on it?
> >
> > If it makes the most sense to take it through that tree, then I'm fine
> > with it but I'd like to hear a rationale.
> 
> I simply thought it would be most convenient, since it touches
> ARM-specific files only. But if you feel it should go via the EFI tree
> instead, that is also fine by me.

Since the diff stat is heavily weighted towards drivers/firmware/efi I
think it should go via the EFI tree. So I'll pick this up (the changes
look fine) unless Will or Catalin complain otherwise.

I'm also keen to allay any concerns that the EFI tree is somehow
x86-specific.

Re: [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks

[Will Deacon]

On Thu, Feb 11, 2016 at 04:29:20PM +0000, Matt Fleming wrote:
> On Thu, 11 Feb, at 05:18:12PM, Ard Biesheuvel wrote:
> > On 11 February 2016 at 17:16, Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:
> > > On Thu, 04 Feb, at 04:50:23PM, Ard Biesheuvel wrote:
> > >> I merged two EFI/ARM related series, whose v1's I sent out last week:
> > >>
> > >> Changes since v1:
> > >> - added various tags from various people
> > >> - new patch #3 to undefine __init
> > >>
> > >> @Matt: are you happy with all of this going through the arm64 tree? I don't
> > >> think it clashes with anything else we've got queued up for v4.6 in tip/efi/core
> > >
> > > How come this is going through the arm64 tree? Are there other patch
> > > series that this depends on or that depend on it?
> > >
> > > If it makes the most sense to take it through that tree, then I'm fine
> > > with it but I'd like to hear a rationale.
> > 
> > I simply thought it would be most convenient, since it touches
> > ARM-specific files only. But if you feel it should go via the EFI tree
> > instead, that is also fine by me.
> 
> Since the diff stat is heavily weighted towards drivers/firmware/efi I
> think it should go via the EFI tree. So I'll pick this up (the changes
> look fine) unless Will or Catalin complain otherwise.

No complaints here (the arm64 bits are all acked).

Will