[PATCH 4.4 013/105] efi: Move some sysfs files to be read-only by root

[PATCH 4.4 013/105] efi: Move some sysfs files to be read-only by root

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af97a77bc01ce49a466f9d4c0125479e2e2230b6 upstream.

Thanks to the scripts/leaking_addresses.pl script, it was found that
some EFI values should not be readable by non-root users.

So make them root-only, and to do that, add a __ATTR_RO_MODE() macro to
make this easier, and use it in other places at the same time.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Tested-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20171206095010.24170-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/firmware/efi/efi.c         |    3 +--
 drivers/firmware/efi/esrt.c        |   15 ++++++---------
 drivers/firmware/efi/runtime-map.c |   10 +++++-----
 include/linux/sysfs.h              |    6 ++++++
 4 files changed, 18 insertions(+), 16 deletions(-)

--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -113,8 +113,7 @@ static ssize_t systab_show(struct kobjec
 	return str - buf;
 }
 
-static struct kobj_attribute efi_attr_systab =
-			__ATTR(systab, 0400, systab_show, NULL);
+static struct kobj_attribute efi_attr_systab = __ATTR_RO_MODE(systab, 0400);
 
 #define EFI_FIELD(var) efi.var
 
--- a/drivers/firmware/efi/esrt.c
+++ b/drivers/firmware/efi/esrt.c
@@ -105,7 +105,7 @@ static const struct sysfs_ops esre_attr_
 };
 
 /* Generic ESRT Entry ("ESRE") support. */
-static ssize_t esre_fw_class_show(struct esre_entry *entry, char *buf)
+static ssize_t fw_class_show(struct esre_entry *entry, char *buf)
 {
 	char *str = buf;
 
@@ -116,18 +116,16 @@ static ssize_t esre_fw_class_show(struct
 	return str - buf;
 }
 
-static struct esre_attribute esre_fw_class = __ATTR(fw_class, 0400,
-	esre_fw_class_show, NULL);
+static struct esre_attribute esre_fw_class = __ATTR_RO_MODE(fw_class, 0400);
 
 #define esre_attr_decl(name, size, fmt) \
-static ssize_t esre_##name##_show(struct esre_entry *entry, char *buf) \
+static ssize_t name##_show(struct esre_entry *entry, char *buf) \
 { \
 	return sprintf(buf, fmt "\n", \
 		       le##size##_to_cpu(entry->esre.esre1->name)); \
 } \
 \
-static struct esre_attribute esre_##name = __ATTR(name, 0400, \
-	esre_##name##_show, NULL)
+static struct esre_attribute esre_##name = __ATTR_RO_MODE(name, 0400)
 
 esre_attr_decl(fw_type, 32, "%u");
 esre_attr_decl(fw_version, 32, "%u");
@@ -195,14 +193,13 @@ static int esre_create_sysfs_entry(void
 
 /* support for displaying ESRT fields at the top level */
 #define esrt_attr_decl(name, size, fmt) \
-static ssize_t esrt_##name##_show(struct kobject *kobj, \
+static ssize_t name##_show(struct kobject *kobj, \
 				  struct kobj_attribute *attr, char *buf)\
 { \
 	return sprintf(buf, fmt "\n", le##size##_to_cpu(esrt->name)); \
 } \
 \
-static struct kobj_attribute esrt_##name = __ATTR(name, 0400, \
-	esrt_##name##_show, NULL)
+static struct kobj_attribute esrt_##name = __ATTR_RO_MODE(name, 0400)
 
 esrt_attr_decl(fw_resource_count, 32, "%u");
 esrt_attr_decl(fw_resource_count_max, 32, "%u");
--- a/drivers/firmware/efi/runtime-map.c
+++ b/drivers/firmware/efi/runtime-map.c
@@ -67,11 +67,11 @@ static ssize_t map_attr_show(struct kobj
 	return map_attr->show(entry, buf);
 }
 
-static struct map_attribute map_type_attr = __ATTR_RO(type);
-static struct map_attribute map_phys_addr_attr   = __ATTR_RO(phys_addr);
-static struct map_attribute map_virt_addr_attr  = __ATTR_RO(virt_addr);
-static struct map_attribute map_num_pages_attr  = __ATTR_RO(num_pages);
-static struct map_attribute map_attribute_attr  = __ATTR_RO(attribute);
+static struct map_attribute map_type_attr = __ATTR_RO_MODE(type, 0400);
+static struct map_attribute map_phys_addr_attr = __ATTR_RO_MODE(phys_addr, 0400);
+static struct map_attribute map_virt_addr_attr = __ATTR_RO_MODE(virt_addr, 0400);
+static struct map_attribute map_num_pages_attr = __ATTR_RO_MODE(num_pages, 0400);
+static struct map_attribute map_attribute_attr = __ATTR_RO_MODE(attribute, 0400);
 
 /*
  * These are default attributes that are added for every memmap entry.
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -116,6 +116,12 @@ struct attribute_group {
 	.show	= _name##_show,						\
 }
 
+#define __ATTR_RO_MODE(_name, _mode) {					\
+	.attr	= { .name = __stringify(_name),				\
+		    .mode = VERIFY_OCTAL_PERMISSIONS(_mode) },		\
+	.show	= _name##_show,						\
+}
+
 #define __ATTR_WO(_name) {						\
 	.attr	= { .name = __stringify(_name), .mode = S_IWUSR },	\
 	.store	= _name##_store,					\

[PATCH 4.4 101/105] Revert "x86/efi: Build our own page table structures"

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 36e0f05afd4e1d09fd47936761a502aedbc50649 which is
commit 67a9108ed4313b85a9c53406d80dc1ae3f8c3e36 upstream.

Turns there was too many other issues with this patch to make it viable
for the stable tree.

Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-efi@vger.kernel.org
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/x86/include/asm/efi.h     |    1 
 arch/x86/platform/efi/efi.c    |   39 ++++++++++------
 arch/x86/platform/efi/efi_32.c |    5 --
 arch/x86/platform/efi/efi_64.c |   97 ++++++-----------------------------------
 4 files changed, 40 insertions(+), 102 deletions(-)

--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -136,7 +136,6 @@ extern void __init efi_memory_uc(u64 add
 extern void __init efi_map_region(efi_memory_desc_t *md);
 extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
 extern void efi_sync_low_kernel_mappings(void);
-extern int __init efi_alloc_page_tables(void);
 extern int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages);
 extern void __init efi_cleanup_page_tables(unsigned long pa_memmap, unsigned num_pages);
 extern void __init old_map_region(efi_memory_desc_t *md);
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -869,7 +869,7 @@ static void __init kexec_enter_virtual_m
  * This function will switch the EFI runtime services to virtual mode.
  * Essentially, we look through the EFI memmap and map every region that
  * has the runtime attribute bit set in its memory descriptor into the
- * efi_pgd page table.
+ * ->trampoline_pgd page table using a top-down VA allocation scheme.
  *
  * The old method which used to update that memory descriptor with the
  * virtual address obtained from ioremap() is still supported when the
@@ -879,8 +879,8 @@ static void __init kexec_enter_virtual_m
  *
  * The new method does a pagetable switch in a preemption-safe manner
  * so that we're in a different address space when calling a runtime
- * function. For function arguments passing we do copy the PUDs of the
- * kernel page table into efi_pgd prior to each call.
+ * function. For function arguments passing we do copy the PGDs of the
+ * kernel page table into ->trampoline_pgd prior to each call.
  *
  * Specially for kexec boot, efi runtime maps in previous kernel should
  * be passed in via setup_data. In that case runtime ranges will be mapped
@@ -895,12 +895,6 @@ static void __init __efi_enter_virtual_m
 
 	efi.systab = NULL;
 
-	if (efi_alloc_page_tables()) {
-		pr_err("Failed to allocate EFI page tables\n");
-		clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
-		return;
-	}
-
 	efi_merge_regions();
 	new_memmap = efi_map_regions(&count, &pg_shift);
 	if (!new_memmap) {
@@ -960,11 +954,28 @@ static void __init __efi_enter_virtual_m
 	efi_runtime_mkexec();
 
 	/*
-	 * We mapped the descriptor array into the EFI pagetable above
-	 * but we're not unmapping it here because if we're running in
-	 * EFI mixed mode we need all of memory to be accessible when
-	 * we pass parameters to the EFI runtime services in the
-	 * thunking code.
+	 * We mapped the descriptor array into the EFI pagetable above but we're
+	 * not unmapping it here. Here's why:
+	 *
+	 * We're copying select PGDs from the kernel page table to the EFI page
+	 * table and when we do so and make changes to those PGDs like unmapping
+	 * stuff from them, those changes appear in the kernel page table and we
+	 * go boom.
+	 *
+	 * From setup_real_mode():
+	 *
+	 * ...
+	 * trampoline_pgd[0] = init_level4_pgt[pgd_index(__PAGE_OFFSET)].pgd;
+	 *
+	 * In this particular case, our allocation is in PGD 0 of the EFI page
+	 * table but we've copied that PGD from PGD[272] of the EFI page table:
+	 *
+	 *	pgd_index(__PAGE_OFFSET = 0xffff880000000000) = 272
+	 *
+	 * where the direct memory mapping in kernel space is.
+	 *
+	 * new_memmap's VA comes from that direct mapping and thus clearing it,
+	 * it would get cleared in the kernel page table too.
 	 *
 	 * efi_cleanup_page_tables(__pa(new_memmap), 1 << pg_shift);
 	 */
--- a/arch/x86/platform/efi/efi_32.c
+++ b/arch/x86/platform/efi/efi_32.c
@@ -38,11 +38,6 @@
  * say 0 - 3G.
  */
 
-int __init efi_alloc_page_tables(void)
-{
-	return 0;
-}
-
 void efi_sync_low_kernel_mappings(void) {}
 void __init efi_dump_pagetable(void) {}
 int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -40,7 +40,6 @@
 #include <asm/fixmap.h>
 #include <asm/realmode.h>
 #include <asm/time.h>
-#include <asm/pgalloc.h>
 
 /*
  * We allocate runtime services regions bottom-up, starting from -4G, i.e.
@@ -122,92 +121,22 @@ void __init efi_call_phys_epilog(pgd_t *
 	early_code_mapping_set_exec(0);
 }
 
-static pgd_t *efi_pgd;
-
-/*
- * We need our own copy of the higher levels of the page tables
- * because we want to avoid inserting EFI region mappings (EFI_VA_END
- * to EFI_VA_START) into the standard kernel page tables. Everything
- * else can be shared, see efi_sync_low_kernel_mappings().
- */
-int __init efi_alloc_page_tables(void)
-{
-	pgd_t *pgd;
-	pud_t *pud;
-	gfp_t gfp_mask;
-
-	if (efi_enabled(EFI_OLD_MEMMAP))
-		return 0;
-
-	gfp_mask = GFP_KERNEL | __GFP_NOTRACK | __GFP_REPEAT | __GFP_ZERO;
-	efi_pgd = (pgd_t *)__get_free_page(gfp_mask);
-	if (!efi_pgd)
-		return -ENOMEM;
-
-	pgd = efi_pgd + pgd_index(EFI_VA_END);
-
-	pud = pud_alloc_one(NULL, 0);
-	if (!pud) {
-		free_page((unsigned long)efi_pgd);
-		return -ENOMEM;
-	}
-
-	pgd_populate(NULL, pgd, pud);
-
-	return 0;
-}
-
 /*
  * Add low kernel mappings for passing arguments to EFI functions.
  */
 void efi_sync_low_kernel_mappings(void)
 {
-	unsigned num_entries;
-	pgd_t *pgd_k, *pgd_efi;
-	pud_t *pud_k, *pud_efi;
+	unsigned num_pgds;
+	pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
 
 	if (efi_enabled(EFI_OLD_MEMMAP))
 		return;
 
-	/*
-	 * We can share all PGD entries apart from the one entry that
-	 * covers the EFI runtime mapping space.
-	 *
-	 * Make sure the EFI runtime region mappings are guaranteed to
-	 * only span a single PGD entry and that the entry also maps
-	 * other important kernel regions.
-	 */
-	BUILD_BUG_ON(pgd_index(EFI_VA_END) != pgd_index(MODULES_END));
-	BUILD_BUG_ON((EFI_VA_START & PGDIR_MASK) !=
-			(EFI_VA_END & PGDIR_MASK));
-
-	pgd_efi = efi_pgd + pgd_index(PAGE_OFFSET);
-	pgd_k = pgd_offset_k(PAGE_OFFSET);
-
-	num_entries = pgd_index(EFI_VA_END) - pgd_index(PAGE_OFFSET);
-	memcpy(pgd_efi, pgd_k, sizeof(pgd_t) * num_entries);
-
-	/*
-	 * We share all the PUD entries apart from those that map the
-	 * EFI regions. Copy around them.
-	 */
-	BUILD_BUG_ON((EFI_VA_START & ~PUD_MASK) != 0);
-	BUILD_BUG_ON((EFI_VA_END & ~PUD_MASK) != 0);
-
-	pgd_efi = efi_pgd + pgd_index(EFI_VA_END);
-	pud_efi = pud_offset(pgd_efi, 0);
-
-	pgd_k = pgd_offset_k(EFI_VA_END);
-	pud_k = pud_offset(pgd_k, 0);
-
-	num_entries = pud_index(EFI_VA_END);
-	memcpy(pud_efi, pud_k, sizeof(pud_t) * num_entries);
+	num_pgds = pgd_index(MODULES_END - 1) - pgd_index(PAGE_OFFSET);
 
-	pud_efi = pud_offset(pgd_efi, EFI_VA_START);
-	pud_k = pud_offset(pgd_k, EFI_VA_START);
-
-	num_entries = PTRS_PER_PUD - pud_index(EFI_VA_START);
-	memcpy(pud_efi, pud_k, sizeof(pud_t) * num_entries);
+	memcpy(pgd + pgd_index(PAGE_OFFSET),
+		init_mm.pgd + pgd_index(PAGE_OFFSET),
+		sizeof(pgd_t) * num_pgds);
 }
 
 int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
@@ -220,8 +149,8 @@ int __init efi_setup_page_tables(unsigne
 	if (efi_enabled(EFI_OLD_MEMMAP))
 		return 0;
 
-	efi_scratch.efi_pgt = (pgd_t *)__pa(efi_pgd);
-	pgd = efi_pgd;
+	efi_scratch.efi_pgt = (pgd_t *)(unsigned long)real_mode_header->trampoline_pgd;
+	pgd = __va(efi_scratch.efi_pgt);
 
 	/*
 	 * It can happen that the physical address of new_memmap lands in memory
@@ -267,14 +196,16 @@ int __init efi_setup_page_tables(unsigne
 
 void __init efi_cleanup_page_tables(unsigned long pa_memmap, unsigned num_pages)
 {
-	kernel_unmap_pages_in_pgd(efi_pgd, pa_memmap, num_pages);
+	pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
+
+	kernel_unmap_pages_in_pgd(pgd, pa_memmap, num_pages);
 }
 
 static void __init __map_region(efi_memory_desc_t *md, u64 va)
 {
+	pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
 	unsigned long flags = 0;
 	unsigned long pfn;
-	pgd_t *pgd = efi_pgd;
 
 	if (!(md->attribute & EFI_MEMORY_WB))
 		flags |= _PAGE_PCD;
@@ -383,7 +314,9 @@ void __init efi_runtime_mkexec(void)
 void __init efi_dump_pagetable(void)
 {
 #ifdef CONFIG_EFI_PGT_DUMP
-	ptdump_walk_pgd_level(NULL, efi_pgd);
+	pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
+
+	ptdump_walk_pgd_level(NULL, pgd);
 #endif
 }
 

[PATCH 4.4 102/105] Revert "x86/efi: Hoist page table switching code into efi_call_virt()"

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit b73adb60852034d84092d123b323196ca42529cd which is
commit c9f2a9a65e4855b74d92cdad688f6ee4a1a323ff upstream.

Turns there was too many other issues with this patch to make it viable
for the stable tree.

Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-efi@vger.kernel.org
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/x86/include/asm/efi.h          |   25 --------------------
 arch/x86/platform/efi/efi_64.c      |   24 ++++++++++----------
 arch/x86/platform/efi/efi_stub_64.S |   43 ++++++++++++++++++++++++++++++++++++
 3 files changed, 56 insertions(+), 36 deletions(-)

--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -3,7 +3,6 @@
 
 #include <asm/fpu/api.h>
 #include <asm/pgtable.h>
-#include <asm/tlb.h>
 
 /*
  * We map the EFI regions needed for runtime services non-contiguously,
@@ -65,17 +64,6 @@ extern u64 asmlinkage efi_call(void *fp,
 
 #define efi_call_phys(f, args...)		efi_call((f), args)
 
-/*
- * Scratch space used for switching the pagetable in the EFI stub
- */
-struct efi_scratch {
-	u64	r15;
-	u64	prev_cr3;
-	pgd_t	*efi_pgt;
-	bool	use_pgd;
-	u64	phys_stack;
-} __packed;
-
 #define efi_call_virt(f, ...)						\
 ({									\
 	efi_status_t __s;						\
@@ -83,20 +71,7 @@ struct efi_scratch {
 	efi_sync_low_kernel_mappings();					\
 	preempt_disable();						\
 	__kernel_fpu_begin();						\
-									\
-	if (efi_scratch.use_pgd) {					\
-		efi_scratch.prev_cr3 = read_cr3();			\
-		write_cr3((unsigned long)efi_scratch.efi_pgt);		\
-		__flush_tlb_all();					\
-	}								\
-									\
 	__s = efi_call((void *)efi.systab->runtime->f, __VA_ARGS__);	\
-									\
-	if (efi_scratch.use_pgd) {					\
-		write_cr3(efi_scratch.prev_cr3);			\
-		__flush_tlb_all();					\
-	}								\
-									\
 	__kernel_fpu_end();						\
 	preempt_enable();						\
 	__s;								\
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -47,7 +47,16 @@
  */
 static u64 efi_va = EFI_VA_START;
 
-struct efi_scratch efi_scratch;
+/*
+ * Scratch space used for switching the pagetable in the EFI stub
+ */
+struct efi_scratch {
+	u64 r15;
+	u64 prev_cr3;
+	pgd_t *efi_pgt;
+	bool use_pgd;
+	u64 phys_stack;
+} __packed;
 
 static void __init early_code_mapping_set_exec(int executable)
 {
@@ -74,11 +83,8 @@ pgd_t * __init efi_call_phys_prolog(void
 	int pgd;
 	int n_pgds;
 
-	if (!efi_enabled(EFI_OLD_MEMMAP)) {
-		save_pgd = (pgd_t *)read_cr3();
-		write_cr3((unsigned long)efi_scratch.efi_pgt);
-		goto out;
-	}
+	if (!efi_enabled(EFI_OLD_MEMMAP))
+		return NULL;
 
 	early_code_mapping_set_exec(1);
 
@@ -90,7 +96,6 @@ pgd_t * __init efi_call_phys_prolog(void
 		vaddress = (unsigned long)__va(pgd * PGDIR_SIZE);
 		set_pgd(pgd_offset_k(pgd * PGDIR_SIZE), *pgd_offset_k(vaddress));
 	}
-out:
 	__flush_tlb_all();
 
 	return save_pgd;
@@ -104,11 +109,8 @@ void __init efi_call_phys_epilog(pgd_t *
 	int pgd_idx;
 	int nr_pgds;
 
-	if (!efi_enabled(EFI_OLD_MEMMAP)) {
-		write_cr3((unsigned long)save_pgd);
-		__flush_tlb_all();
+	if (!save_pgd)
 		return;
-	}
 
 	nr_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT) , PGDIR_SIZE);
 
--- a/arch/x86/platform/efi/efi_stub_64.S
+++ b/arch/x86/platform/efi/efi_stub_64.S
@@ -38,6 +38,41 @@
 	mov %rsi, %cr0;			\
 	mov (%rsp), %rsp
 
+	/* stolen from gcc */
+	.macro FLUSH_TLB_ALL
+	movq %r15, efi_scratch(%rip)
+	movq %r14, efi_scratch+8(%rip)
+	movq %cr4, %r15
+	movq %r15, %r14
+	andb $0x7f, %r14b
+	movq %r14, %cr4
+	movq %r15, %cr4
+	movq efi_scratch+8(%rip), %r14
+	movq efi_scratch(%rip), %r15
+	.endm
+
+	.macro SWITCH_PGT
+	cmpb $0, efi_scratch+24(%rip)
+	je 1f
+	movq %r15, efi_scratch(%rip)		# r15
+	# save previous CR3
+	movq %cr3, %r15
+	movq %r15, efi_scratch+8(%rip)		# prev_cr3
+	movq efi_scratch+16(%rip), %r15		# EFI pgt
+	movq %r15, %cr3
+	1:
+	.endm
+
+	.macro RESTORE_PGT
+	cmpb $0, efi_scratch+24(%rip)
+	je 2f
+	movq efi_scratch+8(%rip), %r15
+	movq %r15, %cr3
+	movq efi_scratch(%rip), %r15
+	FLUSH_TLB_ALL
+	2:
+	.endm
+
 ENTRY(efi_call)
 	SAVE_XMM
 	mov (%rsp), %rax
@@ -48,8 +83,16 @@ ENTRY(efi_call)
 	mov %r8, %r9
 	mov %rcx, %r8
 	mov %rsi, %rcx
+	SWITCH_PGT
 	call *%rdi
+	RESTORE_PGT
 	addq $48, %rsp
 	RESTORE_XMM
 	ret
 ENDPROC(efi_call)
+
+	.data
+ENTRY(efi_scratch)
+	.fill 3,8,0
+	.byte 0
+	.quad 0

[PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is
commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream.

Turns there was too many other issues with this patch to make it viable
for the stable tree.

Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-efi@vger.kernel.org
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/x86/mm/pageattr.c         |   17 +++++++++++------
 arch/x86/platform/efi/efi_64.c |   16 ++++++----------
 2 files changed, 17 insertions(+), 16 deletions(-)

--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -911,10 +911,15 @@ static void populate_pte(struct cpa_data
 	pte = pte_offset_kernel(pmd, start);
 
 	while (num_pages-- && start < end) {
-		set_pte(pte, pfn_pte(cpa->pfn, pgprot));
+
+		/* deal with the NX bit */
+		if (!(pgprot_val(pgprot) & _PAGE_NX))
+			cpa->pfn &= ~_PAGE_NX;
+
+		set_pte(pte, pfn_pte(cpa->pfn >> PAGE_SHIFT, pgprot));
 
 		start	 += PAGE_SIZE;
-		cpa->pfn++;
+		cpa->pfn += PAGE_SIZE;
 		pte++;
 	}
 }
@@ -970,11 +975,11 @@ static int populate_pmd(struct cpa_data
 
 		pmd = pmd_offset(pud, start);
 
-		set_pmd(pmd, __pmd(cpa->pfn << PAGE_SHIFT | _PAGE_PSE |
+		set_pmd(pmd, __pmd(cpa->pfn | _PAGE_PSE |
 				   massage_pgprot(pmd_pgprot)));
 
 		start	  += PMD_SIZE;
-		cpa->pfn  += PMD_SIZE >> PAGE_SHIFT;
+		cpa->pfn  += PMD_SIZE;
 		cur_pages += PMD_SIZE >> PAGE_SHIFT;
 	}
 
@@ -1043,11 +1048,11 @@ static int populate_pud(struct cpa_data
 	 * Map everything starting from the Gb boundary, possibly with 1G pages
 	 */
 	while (end - start >= PUD_SIZE) {
-		set_pud(pud, __pud(cpa->pfn << PAGE_SHIFT | _PAGE_PSE |
+		set_pud(pud, __pud(cpa->pfn | _PAGE_PSE |
 				   massage_pgprot(pud_pgprot)));
 
 		start	  += PUD_SIZE;
-		cpa->pfn  += PUD_SIZE >> PAGE_SHIFT;
+		cpa->pfn  += PUD_SIZE;
 		cur_pages += PUD_SIZE >> PAGE_SHIFT;
 		pud++;
 	}
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -143,7 +143,7 @@ void efi_sync_low_kernel_mappings(void)
 
 int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
 {
-	unsigned long pfn, text;
+	unsigned long text;
 	struct page *page;
 	unsigned npages;
 	pgd_t *pgd;
@@ -160,8 +160,7 @@ int __init efi_setup_page_tables(unsigne
 	 * and ident-map those pages containing the map before calling
 	 * phys_efi_set_virtual_address_map().
 	 */
-	pfn = pa_memmap >> PAGE_SHIFT;
-	if (kernel_map_pages_in_pgd(pgd, pfn, pa_memmap, num_pages, _PAGE_NX)) {
+	if (kernel_map_pages_in_pgd(pgd, pa_memmap, pa_memmap, num_pages, _PAGE_NX)) {
 		pr_err("Error ident-mapping new memmap (0x%lx)!\n", pa_memmap);
 		return 1;
 	}
@@ -186,9 +185,8 @@ int __init efi_setup_page_tables(unsigne
 
 	npages = (_end - _text) >> PAGE_SHIFT;
 	text = __pa(_text);
-	pfn = text >> PAGE_SHIFT;
 
-	if (kernel_map_pages_in_pgd(pgd, pfn, text, npages, 0)) {
+	if (kernel_map_pages_in_pgd(pgd, text >> PAGE_SHIFT, text, npages, 0)) {
 		pr_err("Failed to map kernel text 1:1\n");
 		return 1;
 	}
@@ -206,14 +204,12 @@ void __init efi_cleanup_page_tables(unsi
 static void __init __map_region(efi_memory_desc_t *md, u64 va)
 {
 	pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
-	unsigned long flags = 0;
-	unsigned long pfn;
+	unsigned long pf = 0;
 
 	if (!(md->attribute & EFI_MEMORY_WB))
-		flags |= _PAGE_PCD;
+		pf |= _PAGE_PCD;
 
-	pfn = md->phys_addr >> PAGE_SHIFT;
-	if (kernel_map_pages_in_pgd(pgd, pfn, va, md->num_pages, flags))
+	if (kernel_map_pages_in_pgd(pgd, md->phys_addr, va, md->num_pages, pf))
 		pr_warn("Error mapping PA 0x%llx -> VA 0x%llx!\n",
 			   md->phys_addr, va);
 }

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Roland Dreier]

On Fri, Dec 15, 2017 at 2:20 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is
> commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream.
>
> Turns there was too many other issues with this patch to make it viable
> for the stable tree.

This was sort of a long time ago, but does anyone remember why this
needed to be reverted from 4.4?

The reason I ask is that without this, commit 02ff2769edbc /
"x86/mm/pat: Make set_memory_np() L1TF safe" in 4.4.148 is broken.
That patch has

-               set_pud(pud, __pud(cpa->pfn | _PAGE_PSE |
-                                  massage_pgprot(pud_pgprot)));
+               set_pud(pud, pud_mkhuge(pfn_pud(cpa->pfn,
+                                  canon_pgprot(pud_pgprot))));

(and similarly for pmds) but pfn_pud() is operating on page frame
numbers and __pud(cpa->pfn... in the old code is operating on physical
addresses.

This is bad enough that 4.4.148 and all newer 4.4.y crash early in
boot on some EFI systems that I have.

For now I am re-applying the "ensure cpa->pfn only contains page frame
numbers" patch, ported on top of 4.4.151.

 - R.

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Greg Kroah-Hartman]

On Wed, Aug 22, 2018 at 05:48:32PM -0700, Roland Dreier wrote:
> On Fri, Dec 15, 2017 at 2:20 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is
> > commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream.
> >
> > Turns there was too many other issues with this patch to make it viable
> > for the stable tree.
> 
> This was sort of a long time ago, but does anyone remember why this
> needed to be reverted from 4.4?

I tried to dig through my old emails, but could not find anything,
sorry.

> The reason I ask is that without this, commit 02ff2769edbc /
> "x86/mm/pat: Make set_memory_np() L1TF safe" in 4.4.148 is broken.
> That patch has
> 
> -               set_pud(pud, __pud(cpa->pfn | _PAGE_PSE |
> -                                  massage_pgprot(pud_pgprot)));
> +               set_pud(pud, pud_mkhuge(pfn_pud(cpa->pfn,
> +                                  canon_pgprot(pud_pgprot))));
> 
> (and similarly for pmds) but pfn_pud() is operating on page frame
> numbers and __pud(cpa->pfn... in the old code is operating on physical
> addresses.
> 
> This is bad enough that 4.4.148 and all newer 4.4.y crash early in
> boot on some EFI systems that I have.

Ugh, not good.

> For now I am re-applying the "ensure cpa->pfn only contains page frame
> numbers" patch, ported on top of 4.4.151.

I can try to add it back and see what blows up, want me to attempt that?
:)

thanks,

greg k-h

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Roland Dreier]

> > This is bad enough that 4.4.148 and all newer 4.4.y crash early in
> > boot on some EFI systems that I have.
>
> Ugh, not good.
>
> > For now I am re-applying the "ensure cpa->pfn only contains page frame
> > numbers" patch, ported on top of 4.4.151.
>
> I can try to add it back and see what blows up, want me to attempt that?

Not sure what to say... the current state is obviously broken.  If you
look at what 02ff2769edbc is doing, it's clear that we're now shifting
cpa->pfn by PAGE_SHIFT where we weren't before, so we're putting bogus
values in the page table.  And this is enough that my server system
booting with EFI crashes early in boot efi_enter_virtual_mode() with
the symptom that NX is improperly set on some pages (booting with
"noexec=off" fixes things, although obviously I don't want to run that
way).  FWIW I can confirm that reverting the single patch 02ff2769edbc
fixes things, as does the cpa->pfn fix I mentioned above.

It's hard for me to make a call on applying "ensure cpa->pfn only
contains page frame numbers" without knowing the problems it caused
before.  The patch looks fine to me and I definitely need it, but
maybe it exposes some other bug elsewhere?  Maybe Ben or Matt remember
more above why this was reverted in 4.4.106?  Otherwise I'd say yeah,
we should re-apply it, since I don't think we want to revert
02ff2769edbc.

 - R.

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Matt Fleming]

On Thu, 23 Aug, at 09:37:28AM, Roland Dreier wrote:
> > > This is bad enough that 4.4.148 and all newer 4.4.y crash early in
> > > boot on some EFI systems that I have.
> >
> > Ugh, not good.
> >
> > > For now I am re-applying the "ensure cpa->pfn only contains page frame
> > > numbers" patch, ported on top of 4.4.151.
> >
> > I can try to add it back and see what blows up, want me to attempt that?
> 
> Not sure what to say... the current state is obviously broken.  If you
> look at what 02ff2769edbc is doing, it's clear that we're now shifting
> cpa->pfn by PAGE_SHIFT where we weren't before, so we're putting bogus
> values in the page table.  And this is enough that my server system
> booting with EFI crashes early in boot efi_enter_virtual_mode() with
> the symptom that NX is improperly set on some pages (booting with
> "noexec=off" fixes things, although obviously I don't want to run that
> way).  FWIW I can confirm that reverting the single patch 02ff2769edbc
> fixes things, as does the cpa->pfn fix I mentioned above.
> 
> It's hard for me to make a call on applying "ensure cpa->pfn only
> contains page frame numbers" without knowing the problems it caused
> before.  The patch looks fine to me and I definitely need it, but
> maybe it exposes some other bug elsewhere?  Maybe Ben or Matt remember
> more above why this was reverted in 4.4.106?  Otherwise I'd say yeah,
> we should re-apply it, since I don't think we want to revert
> 02ff2769edbc.

For the record, I wasn't even aware it had been reverted.

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Ben Hutchings]

On Wed, 2018-08-22 at 17:48 -0700, Roland Dreier wrote:
> On Fri, Dec 15, 2017 at 2:20 AM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is
> > commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream.
> > 
> > Turns there was too many other issues with this patch to make it viable
> > for the stable tree.
> 
> This was sort of a long time ago, but does anyone remember why this
> needed to be reverted from 4.4?

See
<https://lore.kernel.org/lkml/1512686629.18523.217.camel@codethink.co.uk/T/#u>.

Ben.

> The reason I ask is that without this, commit 02ff2769edbc /
> "x86/mm/pat: Make set_memory_np() L1TF safe" in 4.4.148 is broken.
> That patch has
> 
> -               set_pud(pud, __pud(cpa->pfn | _PAGE_PSE |
> -                                  massage_pgprot(pud_pgprot)));
> +               set_pud(pud, pud_mkhuge(pfn_pud(cpa->pfn,
> +                                  canon_pgprot(pud_pgprot))));
> 
> (and similarly for pmds) but pfn_pud() is operating on page frame
> numbers and __pud(cpa->pfn... in the old code is operating on physical
> addresses.
> 
> This is bad enough that 4.4.148 and all newer 4.4.y crash early in
> boot on some EFI systems that I have.
> 
> For now I am re-applying the "ensure cpa->pfn only contains page frame
> numbers" patch, ported on top of 4.4.151.
> 
>  - R.
> 
-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Roland Dreier]

> See
> <https://lore.kernel.org/lkml/1512686629.18523.217.camel@codethink.co.uk/T/#u>.

Thanks!  I'm not using SGI UV and I'm not using kexec, so I guess I
sidestepped most of those issues.  Greg, I think we need to unrevert
the cpa->pfn change (otherwise the L1TF fix probably gets pretty
messy) and I guess pull in the other patches that Ben mentions.

 - R.

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Greg Kroah-Hartman]

On Fri, Aug 24, 2018 at 10:08:28AM -0700, Roland Dreier wrote:
> > See
> > <https://lore.kernel.org/lkml/1512686629.18523.217.camel@codethink.co.uk/T/#u>.
> 
> Thanks!  I'm not using SGI UV and I'm not using kexec, so I guess I
> sidestepped most of those issues.  Greg, I think we need to unrevert
> the cpa->pfn change (otherwise the L1TF fix probably gets pretty
> messy) and I guess pull in the other patches that Ben mentions.

Ok, so what patch should be reverted?  I'm seeing other reports of
problems all around this same area, but I can't figure out exactly what
to do.

Guenter, any ideas?

thanks,

greg k-h

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Roland Dreier]

> Ok, so what patch should be reverted?  I'm seeing other reports of
> problems all around this same area, but I can't figure out exactly what
> to do.

Are any of those reports public?  If so can you point me at them, I'm
curious if the symptoms match up.

I don't think we want to revert anything.  I think you should pull in
edc3b9129cec and at least the first three patches that Ben listed:

21cdb6b56843 x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs
b61a76f8850d x86/efi: Map RAM into the identity page table for mixed mode
753b11ef8e92 x86/efi: Setup separate EFI page tables in kexec paths

the first patch takes a bit of massaging (mostly because some of it is
already touched by 02ff2769edbc, which keeps the changes from
edc3b9129cec, and so we can drop a good bit when applying).  The other
three apply cleanly.

I'm currently testing that and can send you the state of my tree in a bit.

 - R.

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Guenter Roeck]

On Fri, Aug 24, 2018 at 09:17:49PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Aug 24, 2018 at 10:08:28AM -0700, Roland Dreier wrote:
> > > See
> > > <https://lore.kernel.org/lkml/1512686629.18523.217.camel@codethink.co.uk/T/#u>.
> > 
> > Thanks!  I'm not using SGI UV and I'm not using kexec, so I guess I
> > sidestepped most of those issues.  Greg, I think we need to unrevert
> > the cpa->pfn change (otherwise the L1TF fix probably gets pretty
> > messy) and I guess pull in the other patches that Ben mentions.
> 
> Ok, so what patch should be reverted?  I'm seeing other reports of
> problems all around this same area, but I can't figure out exactly what
> to do.
> 
> Guenter, any ideas?
> 
I think we'll need to reapply 87e2bd898d3a ("x86/mm/pat: Ensure cpa->pfn only
contains page frame numbers"), and possibly apply d367cef0a7f0 ("x86/mm/pat:
Fix boot crash when 1GB pages are not supported by the CPU"). Both require
conflict resolutions, but they are quite straightforward. I am not sure
about the other EFI patches.

I am going to send the backports as RFT in a minute. Problem is that I don't
have an EFI system at hand and can not test if this fixes the problem
(or maybe introduces a new one), so someone will need to step in and do
those tests.

Guenter

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Guenter Roeck]

On Fri, Aug 24, 2018 at 01:04:09PM -0700, Roland Dreier wrote:
> > Ok, so what patch should be reverted?  I'm seeing other reports of
> > problems all around this same area, but I can't figure out exactly what
> > to do.
> 
> Are any of those reports public?  If so can you point me at them, I'm
> curious if the symptoms match up.
> 
> I don't think we want to revert anything.  I think you should pull in
> edc3b9129cec and at least the first three patches that Ben listed:
> 
> 21cdb6b56843 x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs
> b61a76f8850d x86/efi: Map RAM into the identity page table for mixed mode
> 753b11ef8e92 x86/efi: Setup separate EFI page tables in kexec paths
> 
> the first patch takes a bit of massaging (mostly because some of it is
> already touched by 02ff2769edbc, which keeps the changes from
> edc3b9129cec, and so we can drop a good bit when applying).  The other
> three apply cleanly.
> 
> I'm currently testing that and can send you the state of my tree in a bit.
> 

Sounds great. I'll hold off with sending my RFT series and wait for your
test results. I think we'll also need d367cef0a7f0c6 ("x86/mm/pat: Fix
boot crash when 1GB pages are not supported by the CPU").

Thanks,
Guenter

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Roland Dreier]

> Sounds great. I'll hold off with sending my RFT series and wait for your
> test results. I think we'll also need d367cef0a7f0c6 ("x86/mm/pat: Fix
> boot crash when 1GB pages are not supported by the CPU").

Sure, makes sense - I don't have any EFI systems with CPUs old enough
not to support 1G pages but that looks reasonable.  I'll pull that
into my tree as well.

 - R.

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Guenter Roeck]

On Fri, Aug 24, 2018 at 01:16:18PM -0700, Roland Dreier wrote:
> > Sounds great. I'll hold off with sending my RFT series and wait for your
> > test results. I think we'll also need d367cef0a7f0c6 ("x86/mm/pat: Fix
> > boot crash when 1GB pages are not supported by the CPU").
> 
> Sure, makes sense - I don't have any EFI systems with CPUs old enough
> not to support 1G pages but that looks reasonable.  I'll pull that
> into my tree as well.
> 
kernelci reported a crash on a CPU which doesn't support 1G pages.
See https://kernelci.org/boot/id/5b7d39ea59b514c03796ba9c/

Guenter

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Guenter Roeck]

+Andi Kleen <ak@linux.intel.com>

On Fri, Aug 24, 2018 at 01:04:09PM -0700, Roland Dreier wrote:
> > Ok, so what patch should be reverted?  I'm seeing other reports of
> > problems all around this same area, but I can't figure out exactly what
> > to do.
> 
> Are any of those reports public?  If so can you point me at them, I'm
> curious if the symptoms match up.
> 
> I don't think we want to revert anything.  I think you should pull in
> edc3b9129cec and at least the first three patches that Ben listed:
> 
> 21cdb6b56843 x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs
> b61a76f8850d x86/efi: Map RAM into the identity page table for mixed mode
> 753b11ef8e92 x86/efi: Setup separate EFI page tables in kexec paths
> 
> the first patch takes a bit of massaging (mostly because some of it is
> already touched by 02ff2769edbc, which keeps the changes from
> edc3b9129cec, and so we can drop a good bit when applying).  The other
> three apply cleanly.
> 
> I'm currently testing that and can send you the state of my tree in a bit.
> 
>  - R.

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Guenter Roeck]

Hi Roland,

On 08/24/2018 01:04 PM, Roland Dreier wrote:
>> Ok, so what patch should be reverted?  I'm seeing other reports of
>> problems all around this same area, but I can't figure out exactly what
>> to do.
> 
> Are any of those reports public?  If so can you point me at them, I'm
> curious if the symptoms match up.
> 
> I don't think we want to revert anything.  I think you should pull in
> edc3b9129cec and at least the first three patches that Ben listed:
> 
> 21cdb6b56843 x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs
> b61a76f8850d x86/efi: Map RAM into the identity page table for mixed mode
> 753b11ef8e92 x86/efi: Setup separate EFI page tables in kexec paths
> 
> the first patch takes a bit of massaging (mostly because some of it is
> already touched by 02ff2769edbc, which keeps the changes from
> edc3b9129cec, and so we can drop a good bit when applying).  The other
> three apply cleanly.
> 
> I'm currently testing that and can send you the state of my tree in a bit.
> 

Have you made any progress ? On my side I am still out of luck since I can not
reproduce the problem.

Thanks,
Guenter

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Greg Kroah-Hartman]

On Sat, Aug 25, 2018 at 06:52:32AM -0700, Guenter Roeck wrote:
> Hi Roland,
> 
> On 08/24/2018 01:04 PM, Roland Dreier wrote:
> > > Ok, so what patch should be reverted?  I'm seeing other reports of
> > > problems all around this same area, but I can't figure out exactly what
> > > to do.
> > 
> > Are any of those reports public?  If so can you point me at them, I'm
> > curious if the symptoms match up.
> > 
> > I don't think we want to revert anything.  I think you should pull in
> > edc3b9129cec and at least the first three patches that Ben listed:
> > 
> > 21cdb6b56843 x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs
> > b61a76f8850d x86/efi: Map RAM into the identity page table for mixed mode
> > 753b11ef8e92 x86/efi: Setup separate EFI page tables in kexec paths
> > 
> > the first patch takes a bit of massaging (mostly because some of it is
> > already touched by 02ff2769edbc, which keeps the changes from
> > edc3b9129cec, and so we can drop a good bit when applying).  The other
> > three apply cleanly.
> > 
> > I'm currently testing that and can send you the state of my tree in a bit.
> > 
> 
> Have you made any progress ? On my side I am still out of luck since I can not
> reproduce the problem.

Perhaps just the patch that Andi posted to the stable list helps out
here?

Roland, can you try just that?

thanks,

greg k-h

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Guenter Roeck]

On 08/25/2018 08:07 AM, Greg Kroah-Hartman wrote:
> On Sat, Aug 25, 2018 at 06:52:32AM -0700, Guenter Roeck wrote:
>> Hi Roland,
>>
>> On 08/24/2018 01:04 PM, Roland Dreier wrote:
>>>> Ok, so what patch should be reverted?  I'm seeing other reports of
>>>> problems all around this same area, but I can't figure out exactly what
>>>> to do.
>>>
>>> Are any of those reports public?  If so can you point me at them, I'm
>>> curious if the symptoms match up.
>>>
>>> I don't think we want to revert anything.  I think you should pull in
>>> edc3b9129cec and at least the first three patches that Ben listed:
>>>
>>> 21cdb6b56843 x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs
>>> b61a76f8850d x86/efi: Map RAM into the identity page table for mixed mode
>>> 753b11ef8e92 x86/efi: Setup separate EFI page tables in kexec paths
>>>
>>> the first patch takes a bit of massaging (mostly because some of it is
>>> already touched by 02ff2769edbc, which keeps the changes from
>>> edc3b9129cec, and so we can drop a good bit when applying).  The other
>>> three apply cleanly.
>>>
>>> I'm currently testing that and can send you the state of my tree in a bit.
>>>
>>
>> Have you made any progress ? On my side I am still out of luck since I can not
>> reproduce the problem.
> 
> Perhaps just the patch that Andi posted to the stable list helps out
> here?
> 

For reference:

https://www.spinics.net/lists/stable/msg253357.html

That would be the most straightforward and simple fix, so I would prefer
to go with it if it works.

Guenter

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Roland Dreier]

> > Perhaps just the patch that Andi posted to the stable list helps out
> > here?
> >
>
> For reference:
>
> https://www.spinics.net/lists/stable/msg253357.html
>
> That would be the most straightforward and simple fix, so I would prefer
> to go with it if it works.

Sorry for being slow, it turned out to take a slightly bigger stack of
patches to get everything working.

I agree, Andi's simple fix is better anyway.

 - R.

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Greg Kroah-Hartman]

On Wed, Aug 29, 2018 at 12:58:00PM -0700, Roland Dreier wrote:
> > > Perhaps just the patch that Andi posted to the stable list helps out
> > > here?
> > >
> >
> > For reference:
> >
> > https://www.spinics.net/lists/stable/msg253357.html
> >
> > That would be the most straightforward and simple fix, so I would prefer
> > to go with it if it works.
> 
> Sorry for being slow, it turned out to take a slightly bigger stack of
> patches to get everything working.
> 
> I agree, Andi's simple fix is better anyway.

So 4.4.153 works fine for you now?

thanks,

greg k-h

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Guillaume Tucker]

On 24/08/18 21:32, Guenter Roeck wrote:
> On Fri, Aug 24, 2018 at 01:16:18PM -0700, Roland Dreier wrote:
>>> Sounds great. I'll hold off with sending my RFT series and wait for your
>>> test results. I think we'll also need d367cef0a7f0c6 ("x86/mm/pat: Fix
>>> boot crash when 1GB pages are not supported by the CPU").
>>
>> Sure, makes sense - I don't have any EFI systems with CPUs old enough
>> not to support 1G pages but that looks reasonable.  I'll pull that
>> into my tree as well.
>>
> kernelci reported a crash on a CPU which doesn't support 1G pages.
> See https://kernelci.org/boot/id/5b7d39ea59b514c03796ba9c/

Looks like this has now been fixed with Andi's patch in 4.4.153:

  "x86/mm/pat: Fix L1TF stable backport for CPA"

I can confirm this platform is now booting fine in kernelci:

  http://lava.streamtester.net/scheduler/job/146195

Thanks,
Guillaume

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Greg Kroah-Hartman]

On Fri, Aug 31, 2018 at 07:24:08AM +0100, Guillaume Tucker wrote:
> On 24/08/18 21:32, Guenter Roeck wrote:
> > On Fri, Aug 24, 2018 at 01:16:18PM -0700, Roland Dreier wrote:
> >>> Sounds great. I'll hold off with sending my RFT series and wait for your
> >>> test results. I think we'll also need d367cef0a7f0c6 ("x86/mm/pat: Fix
> >>> boot crash when 1GB pages are not supported by the CPU").
> >>
> >> Sure, makes sense - I don't have any EFI systems with CPUs old enough
> >> not to support 1G pages but that looks reasonable.  I'll pull that
> >> into my tree as well.
> >>
> > kernelci reported a crash on a CPU which doesn't support 1G pages.
> > See https://kernelci.org/boot/id/5b7d39ea59b514c03796ba9c/
> 
> Looks like this has now been fixed with Andi's patch in 4.4.153:
> 
>   "x86/mm/pat: Fix L1TF stable backport for CPA"
> 
> I can confirm this platform is now booting fine in kernelci:
> 
>   http://lava.streamtester.net/scheduler/job/146195

Wonderful, thanks for letting us know.

greg k-h