UEFI: memory attribute table support

Recent UEFI versions expose permission attributes for runtime services memory regions, either in the UEFI memory map or in the separate memory attributes table. This allows the kernel to map these regions with stricter permissions, rather than the RWX permissions that are used by default. So wire this up in our mapping routine.

Note that in the absence of permission attributes, we still only map regions of type EFI_RUNTIME_SERVICE_CODE with the executable bit set. Also, we base the mapping attributes of EFI_MEMORY_MAPPED_IO on the type directly rather than on the absence of the EFI_MEMORY_WB attribute. This is more correct, but is also required for compatibility with the upcoming support for the Memory Attributes Table, which only carries permission attributes, not memory type attributes.

Cc Mark Rutland <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/arm64/kernel/efi.c | 54 +++++++++++++++-----
 1 file changed, 40 insertions(+), 14 deletions(-)

arch/arm64/kernel/efi.c +15 -14

index b6abc852f2a1..33a6da160a50 100644
@@ -17,22 +17,48 @@
 
 #include <asm/efi.h>
 
-int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t
 *md)
+/*
+ * Only regions of type EFI_RUNTIME_SERVICES_CODE need to be
+ * executable, everything else can be mapped with the XN bits
+ * set. Also take the new (optional) RO/XP bits into account.
+ */
+static __init pteval_t create_mapping_protection(efi_memory_desc_t *md)
 {
-	pteval_t prot_val;
+	u64 attr = md->attribute;
+	u32 type = md->type;
 
-	/*
-	 * Only regions of type EFI_RUNTIME_SERVICES_CODE need to be
-	 * executable, everything else can be mapped with the XN bits
-	 * set.
-	 */
-	if ((md->attribute & EFI_MEMORY_WB) == 0)
-		prot_val = PROT_DEVICE_nGnRE;
-	else if (md->type == EFI_RUNTIME_SERVICES_CODE ||
-		 !PAGE_ALIGNED(md->phys_addr))
-		prot_val = pgprot_val(PAGE_KERNEL_EXEC);
-	else
-		prot_val = pgprot_val(PAGE_KERNEL);
+	if (type == EFI_MEMORY_MAPPED_IO)
+		return PROT_DEVICE_nGnRE;
+
+	if (WARN_ONCE(!PAGE_ALIGNED(md->phys_addr),
+		      "UEFI Runtime regions are not aligned to 64 KB --
 buggy firmware?"))
+		/*
+		 * If the region is not aligned to the page size of the

OS, we

arch/arm64/kernel/efi.c +1 -0

+		 * can not use strict permissions, since that would also

affect

arch/arm64/kernel/efi.c +22 -0

+		 * the mapping attributes of the adjacent regions.
+		 */
+		return pgprot_val(PAGE_KERNEL_EXEC);
+
+	/* R-- */
+	if ((attr & (EFI_MEMORY_XP | EFI_MEMORY_RO)) ==
+	    (EFI_MEMORY_XP | EFI_MEMORY_RO))
+		return pgprot_val(PAGE_KERNEL_RO);
+
+	/* R-X */
+	if (attr & EFI_MEMORY_RO)
+		return pgprot_val(PAGE_KERNEL_ROX);
+
+	/* RW- */
+	if (attr & EFI_MEMORY_XP || type != EFI_RUNTIME_SERVICES_CODE)
+		return pgprot_val(PAGE_KERNEL);
+
+	/* RWX */
+	return pgprot_val(PAGE_KERNEL_EXEC);
+}
+
+int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t

*md)

arch/arm64/kernel/efi.c +2 -0

+{
+	pteval_t prot_val = create_mapping_protection(md);
 
 	create_pgd_mapping(mm, md->phys_addr, md->virt_addr,
 			   md->num_pages << EFI_PAGE_SHIFT,

Hi Ard,

This patch causing the kernel boot fail using the UEFI firmware on Qualcomm Technologies QDF2XXX server platforms.

arch/arm64/kernel/efi.c +4 -0

+       /* RW- */
+       if (attr & EFI_MEMORY_XP || type != EFI_RUNTIME_SERVICES_CODE)
+               return pgprot_val(PAGE_KERNEL);
+

Changing above condition from 'or' to 'and' fixed the problem.Are we missing something here or intentionally implemented this logic?

At least
we need some pr_warn here if UEFI firmware passes EFI_RUNTIME_SEVRICE_CODE region that has an attribute EFI_MEMORY_XP.

Quoted 87 lines

Recent UEFI versions expose permission attributes for runtime services memory regions, either in the UEFI memory map or in the separate memory attributes table. This allows the kernel to map these regions with stricter permissions, rather than the RWX permissions that are used by default. So wire this up in our mapping routine.

Note that in the absence of permission attributes, we still only map regions of type EFI_RUNTIME_SERVICE_CODE with the executable bit set. Also, we base the mapping attributes of EFI_MEMORY_MAPPED_IO on the type directly rather than on the absence of the EFI_MEMORY_WB attribute. This is more correct, but is also required for compatibility with the upcoming support for the Memory Attributes Table, which only carries permission attributes, not memory type attributes.

Cc Mark Rutland <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/arm64/kernel/efi.c | 54 +++++++++++++++-----
 1 file changed, 40 insertions(+), 14 deletions(-)

arch/arm64/kernel/efi.c +15 -14

index b6abc852f2a1..33a6da160a50 100644
@@ -17,22 +17,48 @@
 
 #include <asm/efi.h>
 
-int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t
 *md)
+/*
+ * Only regions of type EFI_RUNTIME_SERVICES_CODE need to be
+ * executable, everything else can be mapped with the XN bits
+ * set. Also take the new (optional) RO/XP bits into account.
+ */
+static __init pteval_t create_mapping_protection(efi_memory_desc_t *md)
 {
-     pteval_t prot_val;
+     u64 attr = md->attribute;
+     u32 type = md->type;
 
-     /*
-      * Only regions of type EFI_RUNTIME_SERVICES_CODE need to be
-      * executable, everything else can be mapped with the XN bits
-      * set.
-      */
-     if ((md->attribute & EFI_MEMORY_WB) == 0)
-             prot_val = PROT_DEVICE_nGnRE;
-     else if (md->type == EFI_RUNTIME_SERVICES_CODE ||
-              !PAGE_ALIGNED(md->phys_addr))
-             prot_val = pgprot_val(PAGE_KERNEL_EXEC);
-     else
-             prot_val = pgprot_val(PAGE_KERNEL);
+     if (type == EFI_MEMORY_MAPPED_IO)
+             return PROT_DEVICE_nGnRE;
+
+     if (WARN_ONCE(!PAGE_ALIGNED(md->phys_addr),
+                   "UEFI Runtime regions are not aligned to 64 KB --
 buggy firmware?"))
+             /*
+              * If the region is not aligned to the page size of the

OS, we
+ * can not use strict permissions, since that would also
affect

arch/arm64/kernel/efi.c +22 -0

+              * the mapping attributes of the adjacent regions.
+              */
+             return pgprot_val(PAGE_KERNEL_EXEC);
+
+     /* R-- */
+     if ((attr & (EFI_MEMORY_XP | EFI_MEMORY_RO)) ==
+         (EFI_MEMORY_XP | EFI_MEMORY_RO))
+             return pgprot_val(PAGE_KERNEL_RO);
+
+     /* R-X */
+     if (attr & EFI_MEMORY_RO)
+             return pgprot_val(PAGE_KERNEL_ROX);
+
+     /* RW- */
+     if (attr & EFI_MEMORY_XP || type != EFI_RUNTIME_SERVICES_CODE)
+             return pgprot_val(PAGE_KERNEL);
+
+     /* RWX */
+     return pgprot_val(PAGE_KERNEL_EXEC);
+}
+
+int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t

*md)

arch/arm64/kernel/efi.c line 64

Quoted 5 lines

arch/arm64/kernel/efi.c +2 -0

+{
+     pteval_t prot_val = create_mapping_protection(md);
 
      create_pgd_mapping(mm, md->phys_addr, md->virt_addr,
                         md->num_pages << EFI_PAGE_SHIFT,

--
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Quoted 10 lines · Shanker Donthineni

Hi Ard,

This patch causing the kernel boot fail using the UEFI firmware on Qualcomm Technologies QDF2XXX server platforms.

arch/arm64/kernel/efi.c +4 -0

+       /* RW- */
+       if (attr & EFI_MEMORY_XP || type != EFI_RUNTIME_SERVICES_CODE)
+               return pgprot_val(PAGE_KERNEL);
+

Quoted 2 lines

Changing above condition from 'or' to 'and' fixed the problem.Are we missing something here or intentionally implemented this logic?

The logic is sound, I think. If you need execute permissions on a non-code region with the XP bit set, there is something wrong in the firmware, unless you are hitting this case for an MMIO region perhaps? Could you share the kernel log with efi=debug enabled?

Quoted 4 lines

At least
we need some pr_warn here if UEFI firmware passes EFI_RUNTIME_SEVRICE_CODE region that has an attribute EFI_MEMORY_XP.

No. DXE_RUNTIME_DRIVER modules are implemented as PE/COFF binaries, which are covered completely by EfiRuntimeServicesCode regions. However, a PE/COFF image consists of .text and .data sections, which require different permissions, so PE/COFF binaries are represented by several memory map entries in the memory attributes table, all of which have a code type, but differ in the permission bits.

Quoted 99 lines · Ard Biesheuvel

Quoted 87 lines

Recent UEFI versions expose permission attributes for runtime services memory regions, either in the UEFI memory map or in the separate memory attributes table. This allows the kernel to map these regions with stricter permissions, rather than the RWX permissions that are used by default. So wire this up in our mapping routine.

Note that in the absence of permission attributes, we still only map regions of type EFI_RUNTIME_SERVICE_CODE with the executable bit set. Also, we base the mapping attributes of EFI_MEMORY_MAPPED_IO on the type directly rather than on the absence of the EFI_MEMORY_WB attribute. This is more correct, but is also required for compatibility with the upcoming support for the Memory Attributes Table, which only carries permission attributes, not memory type attributes.

Cc Mark Rutland <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/arm64/kernel/efi.c | 54 +++++++++++++++-----
 1 file changed, 40 insertions(+), 14 deletions(-)

arch/arm64/kernel/efi.c +15 -14

index b6abc852f2a1..33a6da160a50 100644
@@ -17,22 +17,48 @@
 
 #include <asm/efi.h>
 
-int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t
 *md)
+/*
+ * Only regions of type EFI_RUNTIME_SERVICES_CODE need to be
+ * executable, everything else can be mapped with the XN bits
+ * set. Also take the new (optional) RO/XP bits into account.
+ */
+static __init pteval_t create_mapping_protection(efi_memory_desc_t *md)
 {
-     pteval_t prot_val;
+     u64 attr = md->attribute;
+     u32 type = md->type;
 
-     /*
-      * Only regions of type EFI_RUNTIME_SERVICES_CODE need to be
-      * executable, everything else can be mapped with the XN bits
-      * set.
-      */
-     if ((md->attribute & EFI_MEMORY_WB) == 0)
-             prot_val = PROT_DEVICE_nGnRE;
-     else if (md->type == EFI_RUNTIME_SERVICES_CODE ||
-              !PAGE_ALIGNED(md->phys_addr))
-             prot_val = pgprot_val(PAGE_KERNEL_EXEC);
-     else
-             prot_val = pgprot_val(PAGE_KERNEL);
+     if (type == EFI_MEMORY_MAPPED_IO)
+             return PROT_DEVICE_nGnRE;
+
+     if (WARN_ONCE(!PAGE_ALIGNED(md->phys_addr),
+                   "UEFI Runtime regions are not aligned to 64 KB --
 buggy firmware?"))
+             /*
+              * If the region is not aligned to the page size of the

OS, we
+ * can not use strict permissions, since that would also
affect

arch/arm64/kernel/efi.c +22 -0

+              * the mapping attributes of the adjacent regions.
+              */
+             return pgprot_val(PAGE_KERNEL_EXEC);
+
+     /* R-- */
+     if ((attr & (EFI_MEMORY_XP | EFI_MEMORY_RO)) ==
+         (EFI_MEMORY_XP | EFI_MEMORY_RO))
+             return pgprot_val(PAGE_KERNEL_RO);
+
+     /* R-X */
+     if (attr & EFI_MEMORY_RO)
+             return pgprot_val(PAGE_KERNEL_ROX);
+
+     /* RW- */
+     if (attr & EFI_MEMORY_XP || type != EFI_RUNTIME_SERVICES_CODE)
+             return pgprot_val(PAGE_KERNEL);
+
+     /* RWX */
+     return pgprot_val(PAGE_KERNEL_EXEC);
+}
+
+int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t

*md)

arch/arm64/kernel/efi.c line 64

Quoted 5 lines

arch/arm64/kernel/efi.c +2 -0

+{
+     pteval_t prot_val = create_mapping_protection(md);
 
      create_pgd_mapping(mm, md->phys_addr, md->virt_addr,
                         md->num_pages << EFI_PAGE_SHIFT,

--
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Hi Ard,

We are not using the permission attribute table and all the Runtime Data/Code regions are marked with 'XP' bit. Do you think something wrong in our UEFI implementation or Linux has to map RuntimeCode regions with executable permission always irrespective of an attribute flag EFI_MEMORY_XP?

[    0.000000] efi: Processing EFI memory map:
[    0.000000] efi:   0x000000100000-0x00000010ffff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]
[    0.000000] efi:   0x00003b830000-0x00003b83ffff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]
[    0.000000] efi:   0x00003c000000-0x00003fffffff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]
[    0.000000] efi:   0x000000100000-0x00000010ffff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]
[    0.000000] efi:   0x00003b830000-0x00003b83ffff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]
[    0.000000] efi:   0x00003c000000-0x00003fffffff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]
[    0.000000] efi:   0x004000820000-0x00400085ffff [Runtime Data       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x004003080000-0x00400308ffff [Runtime Data       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047f9960000-0x0047f997ffff [Runtime Data       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047fa9c0000-0x0047fa9cffff [Runtime Code       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047faa30000-0x0047faa3ffff [Runtime Code       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047fab90000-0x0047fab9ffff [Runtime Code       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047faba0000-0x0047fabaffff [Runtime Data       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047fab90000-0x0047fab9ffff [Runtime Code       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047faba0000-0x0047fabaffff [Runtime Data       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047fabb0000-0x0047fabbffff [Runtime Code       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*

[    0.000000] efi:   0x0047fabc0000-0x0047fad9ffff [Runtime Data       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047fada0000-0x0047fae2ffff [Runtime Code       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047faf50000-0x0047faf7ffff [Runtime Code       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047fafa0000-0x0047fafbffff [Runtime Code       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047faf50000-0x0047faf7ffff [Runtime Code       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047fafa0000-0x0047fafbffff [Runtime Code       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047fff90000-0x0047fff9ffff [Runtime Code       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0047fffb0000-0x0047fffdffff [Runtime Data       |RUN|  |  |XP|  |  |  |   |WB|WT|WC|UC]*

This implements shared support for discovering the presence of the Memory Attributes table, and for parsing and validating its contents.

The table is validated against the construction rules in the UEFI spec. Since this is a new table, it makes sense to complain if we encounter a table that does not follow those rules.

The parsing and validation routine takes a callback that can be specified per architecture, that gets passed each unique validated region, with the virtual address retrieved from the ordinary memory map.

Signed-off-by Ard Biesheuvel <[email protected]>

---
 drivers/firmware/efi/Makefile  |   2 +-
 drivers/firmware/efi/memattr.c | 170 ++++++++++++++++++++
 include/linux/efi.h            |  13 ++
 3 files changed, 184 insertions(+), 1 deletion(-)

drivers/firmware/efi/Makefile +1 -1

index 62e654f255f4..d5be62399130 100644
@@ -9,7 +9,7 @@
 #
 KASAN_SANITIZE_runtime-wrappers.o      := n
 
-obj-$(CONFIG_EFI)                      += efi.o vars.o reboot.o
+obj-$(CONFIG_EFI)                      += efi.o vars.o reboot.o memattr.o
 obj-$(CONFIG_EFI_VARS)                 += efivars.o
 obj-$(CONFIG_EFI_ESRT)                 += esrt.o
 obj-$(CONFIG_EFI_VARS_PSTORE)          += efi-pstore.o

drivers/firmware/efi/memattr.c new file +170 -0

new file mode 100644
index 000000000000..c55683937f4a
@@ -0,0 +1,170 @@
+/*
+ * Copyright (C) 2016 Linaro Ltd. <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt)    "efi: " fmt
+
+#include <linux/efi.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/memblock.h>
+
+#include <asm/early_ioremap.h>
+
+static int __initdata tbl_size;
+
+/*
+ * Reserve the memory associated with the Memory Attributes configuration
+ * table, if it exists.
+ */
+int __init efi_memattr_init(void)
+{
+       efi_memory_attributes_table_t *tbl;
+
+       if (efi.mem_attr_table == EFI_INVALID_TABLE_ADDR)
+               return 0;
+
+       tbl = early_memremap(efi.mem_attr_table, sizeof(*tbl));
+       if (!tbl) {
+               pr_err("Failed to map EFI Memory Attribute table @ 0x%lx\n",
+                      efi.mem_attr_table);
+               return -ENOMEM;
+       }
+
+       if (tbl->version > 1) {
+               pr_warn("Unexpected EFI Memory Attribute table version %d\n",
+                       tbl->version);
+               tbl_size = 0;
+               goto unmap;
+       }
+
+       tbl_size = sizeof(*tbl) + tbl->num_entries * tbl->desc_size;
+       memblock_reserve(efi.mem_attr_table, tbl_size);
+
+unmap:
+       early_memunmap(tbl, sizeof(*tbl));
+       return 0;
+}
+
+/*
+ * Returns a copy @out of the UEFI memory descriptor @in if it is covered
+ * entirely by a UEFI memory map entry with matching attributes. The virtual
+ * address of @out is set according to the matching entry that was found.
+ */
+static bool entry_is_valid(const efi_memory_desc_t *in, efi_memory_desc_t *out)
+{
+       u64 in_paddr = in->phys_addr;
+       u64 in_size = in->num_pages << EFI_PAGE_SHIFT;
+       efi_memory_desc_t *md;
+
+       if (in->type != EFI_RUNTIME_SERVICES_CODE &&
+           in->type != EFI_RUNTIME_SERVICES_DATA) {
+               pr_warn("MEMATTR table entry type should be RuntimeServiceCode/Data\n");
+               return false;
+       }
+
+       if (!(in->attribute & (EFI_MEMORY_RO | EFI_MEMORY_XP))) {
+               pr_warn("MEMATTR table entry attributes invalid: RO and XP bits both cleared\n");
+               return false;
+       }
+
+       if (PAGE_SIZE > EFI_PAGE_SIZE &&
+           (!PAGE_ALIGNED(in->phys_addr) ||
+            !PAGE_ALIGNED(in->num_pages << EFI_PAGE_SHIFT))) {
+               /*
+                * Since arm64 may execute with page sizes of up to 64 KB, the
+                * UEFI spec mandates that RuntimeServices memory regions must
+                * be 64 KB aligned. We need to validate this here since we will
+                * not be able to tighten permissions on such regions without
+                * affecting adjacent regions.
+                */
+               pr_warn("MEMATTR table entry misaligned\n");
+               return false;
+       }
+
+       for_each_efi_memory_desc(&memmap, md) {
+               u64 md_paddr = md->phys_addr;
+               u64 md_size = md->num_pages << EFI_PAGE_SHIFT;
+
+               if (!(md->attribute & EFI_MEMORY_RUNTIME))
+                       continue;
+               if (md->virt_addr == 0) {
+                       /* no virtual mapping has been installed by the stub */
+                       break;
+               }
+
+               if (md_paddr > in_paddr || (in_paddr - md_paddr) >= md_size)
+                       continue;
+
+               /*
+                * This entry covers the start of @in, check whether
+                * it covers the end as well.
+                */
+               if (md_paddr + md_size < in_paddr + in_size) {
+                       pr_warn("MEMATTR table entry covers multiple UEFI memory map regions\n");
+                       return false;
+               }
+
+               if (md->type != in->type) {
+                       pr_warn("MEMATTR table entry type deviates from UEFI memory map region type\n");
+                       return false;
+               }
+
+               *out = *in;
+               out->virt_addr = in_paddr +
+                                (md->virt_addr - md->phys_addr);
+               return true;
+       }
+       return false;
+}
+
+/*
+ * To be called after the EFI page tables have been populated. If a memory
+ * attributes table is available, its contents will be used to update the
+ * mappings with tightened permissions as described by the table.
+ * This requires the UEFI memory map to have already been populated with
+ * virtual addresses.
+ */
+int __init efi_memattr_apply_permissions(struct mm_struct *mm,
+                                        efi_memattr_perm_setter fn)
+{
+       efi_memory_attributes_table_t *tbl;
+       int i, ret;
+
+       if (tbl_size <= sizeof(*tbl))
+               return 0;
+
+       tbl = memremap(efi.mem_attr_table, tbl_size, MEMREMAP_WB);
+       if (!tbl) {
+               pr_err("Failed to map EFI Memory Attribute table @ 0x%lx\n",
+                      efi.mem_attr_table);
+               return -ENOMEM;
+       }
+
+       if (efi_enabled(EFI_DBG))
+               pr_info("Processing UEFI Memory Attributes table:\n");
+
+       for (i = ret = 0; ret == 0 && i < tbl->num_entries; i++) {
+               efi_memory_desc_t md;
+               unsigned long size;
+               bool valid;
+               char buf[64];
+
+               valid = entry_is_valid((void *)tbl->entry + i * tbl->desc_size,
+                                      &md);
+               size = md.num_pages << EFI_PAGE_SHIFT;
+               if (efi_enabled(EFI_DBG) || !valid)
+                       pr_info("  0x%012llx-0x%012llx %s\n", md.phys_addr,
+                               md.phys_addr + size - 1,
+                               efi_md_typeattr_format(buf, sizeof(buf), &md));
+
+               if (valid)
+                       ret = fn(mm, &md);
+       }
+       memunmap(tbl);
+       return ret;
+}

include/linux/efi.h +13 -1

index 346d01ad7cca..277a9bb4e587 100644
@@ -970,6 +970,19 @@ extern void __init efi_fake_memmap(void);
 static inline void efi_fake_memmap(void) { }
 #endif
 
+/*
+ * efi_memattr_perm_setter - arch specific callback function passed into
+ *                           efi_memattr_apply_permissions() that updates the
+ *                           mapping permissions described by the second
+ *                           argument in the page tables referrred to by the
+ *                           first argument
+ */
+typedef int (*efi_memattr_perm_setter)(struct mm_struct *, efi_memory_desc_t *);
+
+extern int efi_memattr_init(void);
+extern int efi_memattr_apply_permissions(struct mm_struct *mm,
+                                        efi_memattr_perm_setter fn);
+
 /* Iterate through an efi_memory_map */
 #define for_each_efi_memory_desc(m, md)                                           \
        for ((md) = (m)->map;                                              \
--

2.5.0

This implements shared support for discovering the presence of the Memory Attributes table, and for parsing and validating its contents.

The table is validated against the construction rules in the UEFI spec. Since this is a new table, it makes sense to complain if we encounter a table that does not follow those rules.

The parsing and validation routine takes a callback that can be specified per architecture, that gets passed each unique validated region, with the virtual address retrieved from the ordinary memory map.

Signed-off-by Ard Biesheuvel <[email protected]>

---
 drivers/firmware/efi/Makefile  |   2 +-
 drivers/firmware/efi/memattr.c | 170 ++++++++++++++++++++
 include/linux/efi.h            |  13 ++
 3 files changed, 184 insertions(+), 1 deletion(-)

drivers/firmware/efi/memattr.c new file +31 -0

new file mode 100644
index 000000000000..c55683937f4a
@@ -0,0 +1,170 @@
+/*
+ * Copyright (C) 2016 Linaro Ltd. <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt)	"efi: " fmt
+
+#include <linux/efi.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/memblock.h>
+
+#include <asm/early_ioremap.h>
+
+static int __initdata tbl_size;
+
+/*
+ * Reserve the memory associated with the Memory Attributes configuration
+ * table, if it exists.
+ */
+int __init efi_memattr_init(void)
+{
+	efi_memory_attributes_table_t *tbl;
+
+	if (efi.mem_attr_table == EFI_INVALID_TABLE_ADDR)
+		return 0;
+
+	tbl = early_memremap(efi.mem_attr_table, sizeof(*tbl));

drivers/firmware/efi/memattr.c new file +34 -0

+
+	tbl_size = sizeof(*tbl) + tbl->num_entries * tbl->desc_size;
+	memblock_reserve(efi.mem_attr_table, tbl_size);
+
+unmap:
+	early_memunmap(tbl, sizeof(*tbl));
+	return 0;
+}
+
+/*
+ * Returns a copy @out of the UEFI memory descriptor @in if it is covered
+ * entirely by a UEFI memory map entry with matching attributes. The virtual
+ * address of @out is set according to the matching entry that was found.
+ */
+static bool entry_is_valid(const efi_memory_desc_t *in, efi_memory_desc_t *out)
+{
+	u64 in_paddr = in->phys_addr;
+	u64 in_size = in->num_pages << EFI_PAGE_SHIFT;
+	efi_memory_desc_t *md;
+
+	if (in->type != EFI_RUNTIME_SERVICES_CODE &&
+	    in->type != EFI_RUNTIME_SERVICES_DATA) {
+		pr_warn("MEMATTR table entry type should be RuntimeServiceCode/Data\n");
+		return false;
+	}
+
+	if (!(in->attribute & (EFI_MEMORY_RO | EFI_MEMORY_XP))) {
+		pr_warn("MEMATTR table entry attributes invalid: RO and XP bits both cleared\n");
+		return false;
+	}
+
+	if (PAGE_SIZE > EFI_PAGE_SIZE &&
+	    (!PAGE_ALIGNED(in->phys_addr) ||
+	     !PAGE_ALIGNED(in->num_pages << EFI_PAGE_SHIFT))) {

drivers/firmware/efi/memattr.c new file +13 -0

+
+	for_each_efi_memory_desc(&memmap, md) {
+		u64 md_paddr = md->phys_addr;
+		u64 md_size = md->num_pages << EFI_PAGE_SHIFT;
+
+		if (!(md->attribute & EFI_MEMORY_RUNTIME))
+			continue;
+		if (md->virt_addr == 0) {
+			/* no virtual mapping has been installed by the stub */
+			break;
+		}
+
+		if (md_paddr > in_paddr || (in_paddr - md_paddr) >= md_size)

drivers/firmware/efi/memattr.c new file +10 -0

+		return true;
+	}
+	return false;
+}
+
+/*
+ * To be called after the EFI page tables have been populated. If a memory
+ * attributes table is available, its contents will be used to update the
+ * mappings with tightened permissions as described by the table.
+ * This requires the UEFI memory map to have already been populated with

drivers/firmware/efi/memattr.c new file +14 -0

+
+	tbl = memremap(efi.mem_attr_table, tbl_size, MEMREMAP_WB);
+	if (!tbl) {
+		pr_err("Failed to map EFI Memory Attribute table @ 0x%lx\n",
+		       efi.mem_attr_table);
+		return -ENOMEM;
+	}
+
+	if (efi_enabled(EFI_DBG))
+		pr_info("Processing UEFI Memory Attributes table:\n");
+
+	for (i = ret = 0; ret == 0 && i < tbl->num_entries; i++) {
+		efi_memory_desc_t md;
+		unsigned long size;

Quoted 11 lines · Ard Biesheuvel

This implements shared support for discovering the presence of the Memory Attributes table, and for parsing and validating its contents.

The table is validated against the construction rules in the UEFI spec. Since this is a new table, it makes sense to complain if we encounter a table that does not follow those rules.

The parsing and validation routine takes a callback that can be specified per architecture, that gets passed each unique validated region, with the virtual address retrieved from the ordinary memory map.

Quoted 6 lines

Signed-off-by Ard Biesheuvel <[email protected]>

---
 drivers/firmware/efi/Makefile  |   2 +-
 drivers/firmware/efi/memattr.c | 170 ++++++++++++++++++++
 include/linux/efi.h            |  13 ++
 3 files changed, 184 insertions(+), 1 deletion(-)

This commit breaks ia64 because it doesn't provide the global 'memmap' variable,

drivers/built-in.o: In function `efi_memattr_apply_permissions':
(.init.text+0x1f2b0): undefined reference to memmap' drivers/built-in.o: In function efi_memattr_apply_permissions':
(.init.text+0x1f2b1): undefined reference to `memmap'

I was surprised that the kbuild bot didn't let you know, but then I noticed that LKML isn't on Cc. This is yet another reminder that we need to drop 'memmap' on the floor. I'll send out the two patches I have to do that.

Apart from that, this looks pretty good. There are a few comments below, but they're trivial changes that, if you agree, I can just fold in when applying this patch. If not, feel free to rework it.

Quoted 41 lines

drivers/firmware/efi/memattr.c new file +35 -0

new file mode 100644
index 000000000000..c55683937f4a
@@ -0,0 +1,170 @@
+/*
+ * Copyright (C) 2016 Linaro Ltd. <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt)  "efi: " fmt
+
+#include <linux/efi.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/memblock.h>
+
+#include <asm/early_ioremap.h>
+
+static int __initdata tbl_size;
+
+/*
+ * Reserve the memory associated with the Memory Attributes configuration
+ * table, if it exists.
+ */
+int __init efi_memattr_init(void)
+{
+     efi_memory_attributes_table_t *tbl;
+
+     if (efi.mem_attr_table == EFI_INVALID_TABLE_ADDR)
+             return 0;
+
+     tbl = early_memremap(efi.mem_attr_table, sizeof(*tbl));
+     if (!tbl) {
+             pr_err("Failed to map EFI Memory Attribute table @ 0x%lx\n",
+                    efi.mem_attr_table);
+             return -ENOMEM;

drivers/firmware/efi/memattr.c line 41

Quoted 6 lines

drivers/firmware/efi/memattr.c new file +6 -0

+     }
+
+     if (tbl->version > 1) {
+             pr_warn("Unexpected EFI Memory Attribute table version %d\n",
+                     tbl->version);
+             tbl_size = 0;

Isn't it unnecessary to reset 'tbl_size'?

drivers/firmware/efi/memattr.c int __init efi_memattr_init(void) · line 42

Quoted 2 lines

drivers/firmware/efi/memattr.c new file +2 -0

+             goto unmap;
+     }

We should check that the desc_size values match between efi_memory_attributes_table_t and efi_memory_desc_t while we're here validating the table anyway.

Quoted 40 lines

drivers/firmware/efi/memattr.c new file +40 -0

+
+     tbl_size = sizeof(*tbl) + tbl->num_entries * tbl->desc_size;
+     memblock_reserve(efi.mem_attr_table, tbl_size);
+
+unmap:
+     early_memunmap(tbl, sizeof(*tbl));
+     return 0;
+}
+
+/*
+ * Returns a copy @out of the UEFI memory descriptor @in if it is covered
+ * entirely by a UEFI memory map entry with matching attributes. The virtual
+ * address of @out is set according to the matching entry that was found.
+ */
+static bool entry_is_valid(const efi_memory_desc_t *in, efi_memory_desc_t *out)
+{
+     u64 in_paddr = in->phys_addr;
+     u64 in_size = in->num_pages << EFI_PAGE_SHIFT;
+     efi_memory_desc_t *md;
+
+     if (in->type != EFI_RUNTIME_SERVICES_CODE &&
+         in->type != EFI_RUNTIME_SERVICES_DATA) {
+             pr_warn("MEMATTR table entry type should be RuntimeServiceCode/Data\n");
+             return false;
+     }
+
+     if (!(in->attribute & (EFI_MEMORY_RO | EFI_MEMORY_XP))) {
+             pr_warn("MEMATTR table entry attributes invalid: RO and XP bits both cleared\n");
+             return false;
+     }
+
+     if (PAGE_SIZE > EFI_PAGE_SIZE &&
+         (!PAGE_ALIGNED(in->phys_addr) ||
+          !PAGE_ALIGNED(in->num_pages << EFI_PAGE_SHIFT))) {
+             /*
+              * Since arm64 may execute with page sizes of up to 64 KB, the
+              * UEFI spec mandates that RuntimeServices memory regions must
+              * be 64 KB aligned. We need to validate this here since we will
+              * not be able to tighten permissions on such regions without
+              * affecting adjacent regions.

drivers/firmware/efi/memattr.c line 87

Quoted 4 lines

drivers/firmware/efi/memattr.c new file +4 -0

+              */
+             pr_warn("MEMATTR table entry misaligned\n");
+             return false;
+     }

Out of curiosity did you check whether the compiler optimises this out when PAGE_SIZE <= EFI_PAGE_SIZE? I would expect so, and if you haven't already done it already I can check.

Quoted 13 lines

drivers/firmware/efi/memattr.c new file +13 -0

+
+     for_each_efi_memory_desc(&memmap, md) {
+             u64 md_paddr = md->phys_addr;
+             u64 md_size = md->num_pages << EFI_PAGE_SHIFT;
+
+             if (!(md->attribute & EFI_MEMORY_RUNTIME))
+                     continue;
+             if (md->virt_addr == 0) {
+                     /* no virtual mapping has been installed by the stub */
+                     break;
+             }
+
+             if (md_paddr > in_paddr || (in_paddr - md_paddr) >= md_size)

drivers/firmware/efi/memattr.c line 110

Quoted 10 lines

drivers/firmware/efi/memattr.c new file +10 -0

+                     continue;
+
+             /*
+              * This entry covers the start of @in, check whether
+              * it covers the end as well.
+              */
+             if (md_paddr + md_size < in_paddr + in_size) {
+                     pr_warn("MEMATTR table entry covers multiple UEFI memory map regions\n");
+                     return false;
+             }

Here's an interesting tidbit: We never use "UEFI" in strings on x86, we always use "EFI", and of particular relevance to this feature is that "EFI" is used to describe both the memory and memory attribute table in the spec.

How do you feel about the patch at the end of this email?

While I'm OK with breaking the 80 column rule in exceptional circumstances, it was pretty straight forward to update the pr_fmt() macro and cut out a few words from the strings to keep this all within 80 columns.

Quoted 4 lines

drivers/firmware/efi/memattr.c new file +4 -0

+
+             if (md->type != in->type) {
+                     pr_warn("MEMATTR table entry type deviates from UEFI memory map region type\n");
+                     return false;

drivers/firmware/efi/memattr.c line 119

Quoted 5 lines

drivers/firmware/efi/memattr.c new file +5 -0

+             }
+
+             *out = *in;
+             out->virt_addr = in_paddr +
+                              (md->virt_addr - md->phys_addr);

For the benefit of future search-and-replace patches, we should use md_paddr here instead of md->phys_addr.

Quoted 10 lines

drivers/firmware/efi/memattr.c new file +10 -0

+             return true;
+     }
+     return false;
+}
+
+/*
+ * To be called after the EFI page tables have been populated. If a memory
+ * attributes table is available, its contents will be used to update the
+ * mappings with tightened permissions as described by the table.
+ * This requires the UEFI memory map to have already been populated with

drivers/firmware/efi/memattr.c line 139

Quoted 10 lines

drivers/firmware/efi/memattr.c new file +10 -0

+ * virtual addresses.
+ */
+int __init efi_memattr_apply_permissions(struct mm_struct *mm,
+                                      efi_memattr_perm_setter fn)
+{
+     efi_memory_attributes_table_t *tbl;
+     int i, ret;
+
+     if (tbl_size <= sizeof(*tbl))
+             return 0;

We need to check efi_enabled(EFI_MEMMAP) before we start traversing the memory map in entry_is_valid().

Quoted 21 lines

drivers/firmware/efi/memattr.c new file +21 -0

+
+     tbl = memremap(efi.mem_attr_table, tbl_size, MEMREMAP_WB);
+     if (!tbl) {
+             pr_err("Failed to map EFI Memory Attribute table @ 0x%lx\n",
+                    efi.mem_attr_table);
+             return -ENOMEM;
+     }
+
+     if (efi_enabled(EFI_DBG))
+             pr_info("Processing UEFI Memory Attributes table:\n");
+
+     for (i = ret = 0; ret == 0 && i < tbl->num_entries; i++) {
+             efi_memory_desc_t md;
+             unsigned long size;
+             bool valid;
+             char buf[64];
+
+             valid = entry_is_valid((void *)tbl->entry + i * tbl->desc_size,
+                                    &md);
+             size = md.num_pages << EFI_PAGE_SHIFT;
+             if (efi_enabled(EFI_DBG) || !valid)

drivers/firmware/efi/memattr.c line 163

Quoted 3 lines

drivers/firmware/efi/memattr.c new file +3 -0

+                     pr_info("  0x%012llx-0x%012llx %s\n", md.phys_addr,
+                             md.phys_addr + size - 1,
+                             efi_md_typeattr_format(buf, sizeof(buf), &md));

This needs to include some indication of whether we printed this because it was invalid or debug EFI_DBG is set. I've inserted a "!" at the start of the line if it's invalid but if you've got other ideas let me know.

include/linux/efi.h extern void __init efi_fake_memmap(void); · line 977

Quoted 13 lines

include/linux/efi.h +5 -0

index 346d01ad7cca..277a9bb4e587 100644
@@ -970,6 +970,19 @@ extern void __init efi_fake_memmap(void);
 static inline void efi_fake_memmap(void) { }
 #endif
 
+/*
+ * efi_memattr_perm_setter - arch specific callback function passed into
+ *                           efi_memattr_apply_permissions() that updates the
+ *                           mapping permissions described by the second
+ *                           argument in the page tables referrred to by the

Too many 'r's in referred.

---

drivers/firmware/efi/memattr.c +30 -16

index 23973868e186..a983c1b63f07 100644
@@ -6,7 +6,7 @@
  * published by the Free Software Foundation.
  */
 
-#define pr_fmt(fmt)    "efi: " fmt
+#define pr_fmt(fmt)    "efi: memattr: " fmt
 
 #include <linux/efi.h>
 #include <linux/init.h>

@@ -30,15 +30,20 @@ int __init efi_memattr_init(void)
 
        tbl = early_memremap(efi.mem_attr_table, sizeof(*tbl));
        if (!tbl) {
-               pr_err("Failed to map EFI Memory Attribute table @ 0x%lx\n",
+               pr_err("Failed to map EFI Memory Attributes table @ 0x%lx\n",
                       efi.mem_attr_table);
                return -ENOMEM;
        }
 
        if (tbl->version > 1) {
-               pr_warn("Unexpected EFI Memory Attribute table version %d\n",
+               pr_warn("Unexpected EFI Memory Attributes table version %d\n",
                        tbl->version);
-               tbl_size = 0;
+               goto unmap;
+       }
+
+       if (tbl->desc_size != efi.memmap->desc_size) {
+               pr_warn("Descriptor size different from EFI memory map %d\n",
+                       tbl->desc_size);
                goto unmap;
        }
 

@@ -65,12 +70,12 @@ static bool entry_is_valid(const efi_memory_desc_t *in, efi_memory_desc_t *out)
 
        if (in->type != EFI_RUNTIME_SERVICES_CODE &&
            in->type != EFI_RUNTIME_SERVICES_DATA) {
-               pr_warn("MEMATTR table entry type should be RuntimeServiceCode/Data\n");
+               pr_warn("Entry type should be RuntimeServiceCode/Data\n");
                return false;
        }
 
        if (!(in->attribute & (EFI_MEMORY_RO | EFI_MEMORY_XP))) {
-               pr_warn("MEMATTR table entry attributes invalid: RO and XP bits both cleared\n");
+               pr_warn("Entry attributes invalid: RO and XP bits both cleared\n");
                return false;
        }
 

@@ -84,7 +89,7 @@ static bool entry_is_valid(const efi_memory_desc_t *in, efi_memory_desc_t *out)
                 * not be able to tighten permissions on such regions without
                 * affecting adjacent regions.
                 */
-               pr_warn("MEMATTR table entry misaligned\n");
+               pr_warn("Entry address region misaligned\n");
                return false;
        }
 

@@ -107,22 +112,21 @@ static bool entry_is_valid(const efi_memory_desc_t *in, efi_memory_desc_t *out)
                 * it covers the end as well.
                 */
                if (md_paddr + md_size < in_paddr + in_size) {
-                       pr_warn("MEMATTR table entry covers multiple UEFI memory map regions\n");
+                       pr_warn("Entry covers multiple EFI memory map regions\n");
                        return false;
                }
 
                if (md->type != in->type) {
-                       pr_warn("MEMATTR table entry type deviates from UEFI memory map region type\n");
+                       pr_warn("Entry type deviates from EFI memory map region type\n");
                        return false;
                }
 
-               out->virt_addr = in_paddr +
-                                (md->virt_addr - md->phys_addr);
+               out->virt_addr = in_paddr + (md->virt_addr - md_paddr);
+
                return true;
        }
 
-       pr_warn("MEMATTR table entry does not having a matching entry in the memory map\n");
-
+       pr_warn("No matching entry found in the EFI memory map\n");
        return false;
 }
 

@@ -142,15 +146,24 @@ int __init efi_memattr_apply_permissions(struct mm_struct *mm,
        if (tbl_size <= sizeof(*tbl))
                return 0;
 
+       /*
+        * We need the EFI memory map to be setup so we can use it to
+        * lookup the virtual addresses of all entries in the  of EFI
+        * Memory Attributes table. If it isn't available, this
+        * function should not be called.
+        */
+       if (WARN_ON(!efi_enabled(EFI_MEMMAP)))
+               return 0;
+
        tbl = memremap(efi.mem_attr_table, tbl_size, MEMREMAP_WB);
        if (!tbl) {
-               pr_err("Failed to map EFI Memory Attribute table @ 0x%lx\n",
+               pr_err("Failed to map EFI Memory Attributes table @ 0x%lx\n",
                       efi.mem_attr_table);
                return -ENOMEM;
        }
 
        if (efi_enabled(EFI_DBG))
-               pr_info("Processing UEFI Memory Attributes table:\n");
+               pr_info("Processing EFI Memory Attributes table:\n");
 
        for (i = ret = 0; ret == 0 && i < tbl->num_entries; i++) {
                efi_memory_desc_t md;

@@ -162,7 +175,8 @@ int __init efi_memattr_apply_permissions(struct mm_struct *mm,
                                       &md);
                size = md.num_pages << EFI_PAGE_SHIFT;
                if (efi_enabled(EFI_DBG) || !valid)
-                       pr_info("  0x%012llx-0x%012llx %s\n", md.phys_addr,
+                       pr_info("%s 0x%012llx-0x%012llx %s\n",
+                               valid ? "" : "!", md.phys_addr,
                                md.phys_addr + size - 1,
                                efi_md_typeattr_format(buf, sizeof(buf), &md));
 

include/linux/efi.h +2 -2

index bb404979f4bd..c80895e4e505 100644
@@ -974,8 +974,8 @@ static inline void efi_fake_memmap(void) { }
  * efi_memattr_perm_setter - arch specific callback function passed into
  *                           efi_memattr_apply_permissions() that updates the
  *                           mapping permissions described by the second
- *                           argument in the page tables referrred to by the
- *                           first argument
+ *                           argument in the page tables referred to by the
+ *                           first argument.
  */
 typedef int (*efi_memattr_perm_setter)(struct mm_struct *, efi_memory_desc_t *);
 

The spec does not actually mandate that, and I do know that the Tianocore code deliberately uses a larger value for desc_size in GetMemoryMap() to catch inadvertent uses of sizeof(). I am not sure if the memory attribute table code does the same, and it seems dangerous to assume that to be the case in general.

Quoted 6 lines · Ard Biesheuvel

The spec does not actually mandate that, and I do know that the Tianocore code deliberately uses a larger value for desc_size in GetMemoryMap() to catch inadvertent uses of sizeof(). I am not sure if the memory attribute table code does the same, and it seems dangerous to assume that to be the case in general.

The spec may not mandate that, but this code will explode horribly if efi_memory_desc_t does not accurately describe the entries in either the EFI Memory Attributes table or the EFI memory map.

How do we ensure that doing,

static bool entry_is_valid(...)

{
        *out = *in;
        ...

keeps working? Are we using the table version to guarantee that?

I think it is implied by the spec that this table and the one returned by GetMemoryMap() use mutually compatible definitions of EFI_MEMORY_DESCRIPTOR. However, since our definition of the struct type is based on version 1, we should perhaps add a check for that separately

Quoted 6 lines · Ard Biesheuvel

I think it is implied by the spec that this table and the one returned by GetMemoryMap() use mutually compatible definitions of EFI_MEMORY_DESCRIPTOR. However, since our definition of the struct type is based on version 1, we should perhaps add a check for that separately

That makes sense. Could you send a patch for that on top of 'next' (I've dropped the desc_size check now)?