Skip to contentSkip to conversation

4.4.110-stable review

PATCH In review Greg Kroah-Hartman 22 participants 147 messages Jan 3, 2018 – Jan 12, 2018

Subsystems (5)
lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 4.4.110-stable review

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.110-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 4.4.110-rc1

Kees Cook <[email protected]>
KPTI: Report when enabled

Kees Cook <[email protected]>
KPTI: Rename to PAGE_TABLE_ISOLATION

Borislav Petkov <[email protected]>
x86/kaiser: Move feature detection up

Jiri Kosina <[email protected]>
kaiser: disabled on Xen PV

Borislav Petkov <[email protected]>
x86/kaiser: Reenable PARAVIRT

Thomas Gleixner <[email protected]>
x86/paravirt: Dont patch flush_tlb_single

Hugh Dickins <[email protected]>
kaiser: kaiser_flush_tlb_on_return_to_user() check PCID

Hugh Dickins <[email protected]>
kaiser: asm/tlbflush.h handle noPGE at lower level

Hugh Dickins <[email protected]>
kaiser: drop is_atomic arg to kaiser_pagetable_walk()

Hugh Dickins <[email protected]>
kaiser: use ALTERNATIVE instead of x86_cr3_pcid_noflush

Borislav Petkov <[email protected]>
x86/kaiser: Check boottime cmdline params

Borislav Petkov <[email protected]>
x86/kaiser: Rename and simplify X86_FEATURE_KAISER handling

Hugh Dickins <[email protected]>
kaiser: add "nokaiser" boot option, using ALTERNATIVE

Hugh Dickins <[email protected]>
kaiser: fix unlikely error in alloc_ldt_struct()

Hugh Dickins <[email protected]>
kaiser: _pgd_alloc() without __GFP_REPEAT to avoid stalls

Hugh Dickins <[email protected]>
kaiser: paranoid_entry pass cr3 need to paranoid_exit

Hugh Dickins <[email protected]>

    kaiser: x86_cr3_pcid_noflush and x86_cr3_pcid_user

Hugh Dickins <[email protected]>
kaiser: PCID 0 for kernel and 128 for user

Hugh Dickins <[email protected]>
kaiser: load_new_mm_cr3() let SWITCH_USER_CR3 flush user

Dave Hansen <[email protected]>
kaiser: enhanced by kernel and user PCIDs

Hugh Dickins <[email protected]>
kaiser: vmstat show NR_KAISERTABLE as nr_overhead

Hugh Dickins <[email protected]>
kaiser: delete KAISER_REAL_SWITCH option

Hugh Dickins <[email protected]>

    kaiser: name that 0x1000 KAISER_SHADOW_PGD_OFFSET

Hugh Dickins <[email protected]>
kaiser: cleanups while trying for gold link

Hugh Dickins <[email protected]>
kaiser: kaiser_remove_mapping() move along the pgd

Hugh Dickins <[email protected]>
kaiser: tidied up kaiser_add/remove_mapping slightly

Hugh Dickins <[email protected]>
kaiser: tidied up asm/kaiser.h somewhat

Hugh Dickins <[email protected]>
kaiser: ENOMEM if kaiser_pagetable_walk() NULL

Hugh Dickins <[email protected]>
kaiser: fix perf crashes

Hugh Dickins <[email protected]>
kaiser: fix regs to do_nmi() ifndef CONFIG_KAISER

Hugh Dickins <[email protected]>
kaiser: KAISER depends on SMP

Hugh Dickins <[email protected]>
kaiser: fix build and FIXME in alloc_ldt_struct()

Hugh Dickins <[email protected]>
kaiser: stack map PAGE_SIZE at THREAD_SIZE-PAGE_SIZE

Hugh Dickins <[email protected]>
kaiser: do not set _PAGE_NX on pgd_none

Dave Hansen <[email protected]>
kaiser: merged update

Richard Fellner <[email protected]>
KAISER: Kernel Address Isolation

Tom Lendacky <[email protected]>
x86/boot: Add early cmdline parsing for options with arguments

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

Diffstat:

 Documentation/kernel-parameters.txt         |   8 +
 Makefile                                    |   4 +-
 arch/x86/boot/compressed/misc.h             |   1 +
 arch/x86/entry/entry_64.S                   | 164 ++++++++--
 arch/x86/entry/entry_64_compat.S            |   7 +
 arch/x86/include/asm/cmdline.h              |   2 +
 arch/x86/include/asm/cpufeature.h           |   4 +
 arch/x86/include/asm/desc.h                 |   2 +-
 arch/x86/include/asm/hw_irq.h               |   2 +-
 arch/x86/include/asm/kaiser.h               | 141 +++++++++
 arch/x86/include/asm/pgtable.h              |  28 +-
 arch/x86/include/asm/pgtable_64.h           |  25 +-
 arch/x86/include/asm/pgtable_types.h        |  29 +-
 arch/x86/include/asm/processor.h            |   2 +-
 arch/x86/include/asm/tlbflush.h             |  74 ++++-
 arch/x86/include/uapi/asm/processor-flags.h |   3 +-
 arch/x86/kernel/cpu/common.c                |  28 +-
 arch/x86/kernel/cpu/perf_event_intel_ds.c   |  57 +++-
 arch/x86/kernel/espfix_64.c                 |  10 +
 arch/x86/kernel/head_64.S                   |  35 ++-
 arch/x86/kernel/irqinit.c                   |   2 +-
 arch/x86/kernel/ldt.c                       |  25 +-
 arch/x86/kernel/paravirt_patch_64.c         |   2 -
 arch/x86/kernel/process.c                   |   2 +-
 arch/x86/kernel/setup.c                     |   7 +
 arch/x86/kernel/tracepoint.c                |   2 +
 arch/x86/kvm/x86.c                          |   3 +-
 arch/x86/lib/cmdline.c                      | 105 +++++++
 arch/x86/mm/Makefile                        |   1 +
 arch/x86/mm/init.c                          |   2 +-
 arch/x86/mm/init_64.c                       |  10 +
 arch/x86/mm/kaiser.c                        | 455 ++++++++++++++++++++++++++++
 arch/x86/mm/pageattr.c                      |  63 +++-
 arch/x86/mm/pgtable.c                       |  16 +-
 arch/x86/mm/tlb.c                           |  39 ++-
 include/asm-generic/vmlinux.lds.h           |   7 +
 include/linux/kaiser.h                      |  52 ++++
 include/linux/mmzone.h                      |   3 +-
 include/linux/percpu-defs.h                 |  32 +-
 init/main.c                                 |   2 +
 kernel/fork.c                               |   6 +
 mm/vmstat.c                                 |   1 +
 security/Kconfig                            |  10 +
 43 files changed, 1375 insertions(+), 98 deletions(-)
author maintainer
#1 lore raw

PATCH 1/37 x86/boot: Add early cmdline parsing for options with arguments

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

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

From: Tom Lendacky <[email protected]>

commit e505371dd83963caae1a37ead9524e8d997341be upstream.

Add a cmdline_find_option() function to look for cmdline options that take arguments. The argument is returned in a supplied buffer and the argument length (regardless of whether it fits in the supplied buffer) is returned, with -1 indicating not found.

---
 arch/x86/include/asm/cmdline.h |    2 
 arch/x86/lib/cmdline.c         |  105 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 107 insertions(+)
arch/x86/include/asm/cmdline.h +2 -0
@@ -2,5 +2,7 @@
 #define _ASM_X86_CMDLINE_H
 
 int cmdline_find_option_bool(const char *cmdline_ptr, const char *option);
+int cmdline_find_option(const char *cmdline_ptr, const char *option,
+			char *buffer, int bufsize);
 
 #endif /* _ASM_X86_CMDLINE_H */
arch/x86/lib/cmdline.c +105 -0

108 lines not on this page · raw message

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

author maintainer
#2 lore raw

PATCH 2/37 KAISER: Kernel Address Isolation

In reply to Greg Kroah-Hartman

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

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

From: Richard Fellner <[email protected]>

This patch introduces our implementation of KAISER (Kernel Address Isolation to have Side-channels Efficiently Removed), a kernel isolation technique to close hardware side channels on kernel address information.

More information about the patch can be found on:

https://github.com/IAIK/KAISER

From: Richard Fellner <[email protected]>
From: Daniel Gruss <[email protected]>
X-Subject: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode
Date: Thu, 4 May 2017 14:26:50 +0200

Kaiser-4.10-SHA1: c4b1831d44c6144d3762ccc72f0c4e71a0c713e5

To: <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: Michael Schwarz <[email protected]>
Cc: Richard Fellner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>

After several recent works [1,2,3] KASLR on x86_64 was basically considered dead by many researchers. We have been working on an efficient but effective fix for this problem and found that not mapping the kernel space when running in user mode is the solution to this problem [4] (the corresponding paper [5] will be presented at ESSoS17).

With this RFC patch we allow anybody to configure their kernel with the flag CONFIG_KAISER to add our defense mechanism.

If there are any questions we would love to answer them. We also appreciate any comments!

Cheers,
Daniel (+ the KAISER team from Graz University of Technology)

[1] http://www.ieee-security.org/TC/SP2013/papers/4977a191.pdf
[2] https://www.blackhat.com/docs/us-16/materials/us-16-Fogh-Using-Undocumented-CPU-Behaviour-To-See-Into-Kernel-Mode-And-Break-KASLR-In-The-Process.pdf
[3] https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Kernel-Address-Space-Layout-Randomization-KASLR-With-Intel-TSX.pdf
[4] https://github.com/IAIK/KAISER
[5] https://gruss.cc/files/kaiser.pdf

[patch based also on
https://raw.githubusercontent.com/IAIK/KAISER/master/KAISER/0001-KAISER-Kernel-Address-Isolation.patch]

---
 arch/x86/entry/entry_64.S            |   19 +++-
 arch/x86/entry/entry_64_compat.S     |    6 +
 arch/x86/include/asm/hw_irq.h        |    2 
 arch/x86/include/asm/kaiser.h        |  113 ++++++++++++++++++++++++
 arch/x86/include/asm/pgtable.h       |    4 
 arch/x86/include/asm/pgtable_64.h    |   21 ++++
 arch/x86/include/asm/pgtable_types.h |   12 ++
 arch/x86/include/asm/processor.h     |    7 +
 arch/x86/kernel/cpu/common.c         |    4 
 arch/x86/kernel/espfix_64.c          |    6 +
 arch/x86/kernel/head_64.S            |   16 ++-
 arch/x86/kernel/irqinit.c            |    2 
 arch/x86/kernel/process.c            |    2 
 arch/x86/mm/Makefile                 |    1 
 arch/x86/mm/kaiser.c                 |  160 +++++++++++++++++++++++++++++++++++
 arch/x86/mm/pageattr.c               |    2 
 arch/x86/mm/pgtable.c                |   26 +++++
 include/asm-generic/vmlinux.lds.h    |   11 ++
 include/linux/percpu-defs.h          |   30 ++++++
 init/main.c                          |    6 +
 kernel/fork.c                        |    8 +
 security/Kconfig                     |    7 +
 22 files changed, 449 insertions(+), 16 deletions(-)
 create mode 100644 arch/x86/include/asm/kaiser.h
 create mode 100644 arch/x86/mm/kaiser.c
arch/x86/entry/entry_64.S +17 -2
@@ -35,6 +35,7 @@
 #include <asm/asm.h>
 #include <asm/smap.h>
 #include <asm/pgtable_types.h>
+#include <asm/kaiser.h>
 #include <linux/err.h>
 
 /* Avoid __ASSEMBLER__'ifying <linux/audit.h> just for this.  */
@@ -135,6 +136,7 @@ ENTRY(entry_SYSCALL_64)
 	 * it is too small to ever cause noticeable irq latency.
 	 */
 	SWAPGS_UNSAFE_STACK
+	SWITCH_KERNEL_CR3_NO_STACK
 	/*
 	 * A hypervisor implementation might want to use a label
 	 * after the swapgs, so that it can do the swapgs
@@ -207,9 +209,10 @@ entry_SYSCALL_64_fastpath:
 	testl	$_TIF_ALLWORK_MASK, ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS)
 	jnz	int_ret_from_sys_call_irqs_off	/* Go to the slow path */
 
-	RESTORE_C_REGS_EXCEPT_RCX_R11
 	movq	RIP(%rsp), %rcx
 	movq	EFLAGS(%rsp), %r11
+	RESTORE_C_REGS_EXCEPT_RCX_R11
+	SWITCH_USER_CR3
 	movq	RSP(%rsp), %rsp
 	/*
 	 * 64-bit SYSRET restores rip from rcx,
@@ -347,10 +350,12 @@ GLOBAL(int_ret_from_sys_call)
 syscall_return_via_sysret:
 	/* rcx and r11 are already restored (see code above) */
 	RESTORE_C_REGS_EXCEPT_RCX_R11
+	SWITCH_USER_CR3
 	movq	RSP(%rsp), %rsp
 	USERGS_SYSRET64
 
 opportunistic_sysret_failed:
+	SWITCH_USER_CR3
 	SWAPGS
 	jmp	restore_c_regs_and_iret
 END(entry_SYSCALL_64)
@@ -509,6 +514,7 @@ END(irq_entries_start)
 	 * tracking that we're in kernel mode.
 	 */
 	SWAPGS
+	SWITCH_KERNEL_CR3
 
 	/*
 	 * We need to tell lockdep that IRQs are off.  We can't do this until
@@ -568,6 +574,7 @@ GLOBAL(retint_user)
 	mov	%rsp,%rdi
 	call	prepare_exit_to_usermode
 	TRACE_IRQS_IRETQ
+	SWITCH_USER_CR3
 	SWAPGS
 	jmp	restore_regs_and_iret
 
@@ -625,6 +632,7 @@ native_irq_return_ldt:
 	pushq	%rax
 	pushq	%rdi
 	SWAPGS
+	SWITCH_KERNEL_CR3
 	movq	PER_CPU_VAR(espfix_waddr), %rdi
 	movq	%rax, (0*8)(%rdi)		/* RAX */
 	movq	(2*8)(%rsp), %rax		/* RIP */
@@ -640,6 +648,7 @@ native_irq_return_ldt:
 	andl	$0xffff0000, %eax
 	popq	%rdi
 	orq	PER_CPU_VAR(espfix_stack), %rax
+	SWITCH_USER_CR3
 	SWAPGS
 	movq	%rax, %rsp
 	popq	%rax
@@ -1007,6 +1016,7 @@ ENTRY(paranoid_entry)
 	testl	%edx, %edx
 	js	1f				/* negative -> in kernel */
 	SWAPGS
+	SWITCH_KERNEL_CR3
 	xorl	%ebx, %ebx
 1:	ret
 END(paranoid_entry)
@@ -1029,6 +1039,7 @@ ENTRY(paranoid_exit)
 	testl	%ebx, %ebx			/* swapgs needed? */
 	jnz	paranoid_exit_no_swapgs
 	TRACE_IRQS_IRETQ
+	SWITCH_USER_CR3_NO_STACK
 	SWAPGS_UNSAFE_STACK
 	jmp	paranoid_exit_restore
 paranoid_exit_no_swapgs:
@@ -1058,6 +1069,7 @@ ENTRY(error_entry)
 	 * from user mode due to an IRET fault.
 	 */
 	SWAPGS
+	SWITCH_KERNEL_CR3
 
 .Lerror_entry_from_usermode_after_swapgs:
 	/*
@@ -1110,7 +1122,7 @@ ENTRY(error_entry)
 	 * Switch to kernel gsbase:
 	 */
 	SWAPGS
-
+	SWITCH_KERNEL_CR3
 	/*
 	 * Pretend that the exception came from user mode: set up pt_regs
 	 * as if we faulted immediately after IRET and clear EBX so that
@@ -1210,6 +1222,7 @@ ENTRY(nmi)
 	 */
 
 	SWAPGS_UNSAFE_STACK
+	SWITCH_KERNEL_CR3_NO_STACK
 	cld
 	movq	%rsp, %rdx
 	movq	PER_CPU_VAR(cpu_current_top_of_stack), %rsp
@@ -1250,6 +1263,7 @@ ENTRY(nmi)
 	 * work, because we don't want to enable interrupts.  Fortunately,
 	 * do_nmi doesn't modify pt_regs.
 	 */
+	SWITCH_USER_CR3
 	SWAPGS
 	jmp	restore_c_regs_and_iret
 
@@ -1461,6 +1475,7 @@ end_repeat_nmi:
 	testl	%ebx, %ebx			/* swapgs needed? */
 	jnz	nmi_restore
 nmi_swapgs:
+	SWITCH_USER_CR3_NO_STACK
 	SWAPGS_UNSAFE_STACK
 nmi_restore:
 	RESTORE_EXTRA_REGS
arch/x86/entry/entry_64_compat.S +6 -0
@@ -13,6 +13,7 @@
 #include <asm/irqflags.h>
 #include <asm/asm.h>
 #include <asm/smap.h>
+#include <asm/kaiser.h>
 #include <linux/linkage.h>
 #include <linux/err.h>
 
@@ -50,6 +51,7 @@ ENDPROC(native_usergs_sysret32)
 ENTRY(entry_SYSENTER_compat)
 	/* Interrupts are off on entry. */
 	SWAPGS_UNSAFE_STACK
+	SWITCH_KERNEL_CR3_NO_STACK
 	movq	PER_CPU_VAR(cpu_current_top_of_stack), %rsp
 
 	/*
@@ -161,6 +163,7 @@ ENDPROC(entry_SYSENTER_compat)
 ENTRY(entry_SYSCALL_compat)
 	/* Interrupts are off on entry. */
 	SWAPGS_UNSAFE_STACK
+	SWITCH_KERNEL_CR3_NO_STACK
 
 	/* Stash user ESP and switch to the kernel stack. */
 	movl	%esp, %r8d
@@ -208,6 +211,7 @@ ENTRY(entry_SYSCALL_compat)
 	/* Opportunistic SYSRET */
 sysret32_from_system_call:
 	TRACE_IRQS_ON			/* User mode traces as IRQs on. */
+	SWITCH_USER_CR3
 	movq	RBX(%rsp), %rbx		/* pt_regs->rbx */
 	movq	RBP(%rsp), %rbp		/* pt_regs->rbp */
 	movq	EFLAGS(%rsp), %r11	/* pt_regs->flags (in r11) */
@@ -269,6 +273,7 @@ ENTRY(entry_INT80_compat)
 	PARAVIRT_ADJUST_EXCEPTION_FRAME
 	ASM_CLAC			/* Do this early to minimize exposure */
 	SWAPGS
+	SWITCH_KERNEL_CR3_NO_STACK
 
 	/*
 	 * User tracing code (ptrace or signal handlers) might assume that
@@ -311,6 +316,7 @@ ENTRY(entry_INT80_compat)
 
 	/* Go back to user mode. */
 	TRACE_IRQS_ON
+	SWITCH_USER_CR3
 	SWAPGS
 	jmp	restore_regs_and_iret
 END(entry_INT80_compat)
arch/x86/include/asm/hw_irq.h +1 -1
@@ -187,7 +187,7 @@ extern char irq_entries_start[];
 #define VECTOR_RETRIGGERED	((void *)~0UL)
 
 typedef struct irq_desc* vector_irq_t[NR_VECTORS];
-DECLARE_PER_CPU(vector_irq_t, vector_irq);
+DECLARE_PER_CPU_USER_MAPPED(vector_irq_t, vector_irq);
 
 #endif /* !ASSEMBLY_ */
 
arch/x86/include/asm/kaiser.h new file +113 -0

113 lines not on this page · raw message

arch/x86/include/asm/pgtable.h +4 -0
@@ -856,6 +856,10 @@ static inline void pmdp_set_wrprotect(st
 static inline void clone_pgd_range(pgd_t *dst, pgd_t *src, int count)
 {
        memcpy(dst, src, count * sizeof(pgd_t));
+#ifdef CONFIG_KAISER
+	// clone the shadow pgd part as well
+	memcpy(native_get_shadow_pgd(dst), native_get_shadow_pgd(src), count * sizeof(pgd_t));
+#endif
 }
 
 #define PTE_SHIFT ilog2(PTRS_PER_PTE)
arch/x86/include/asm/pgtable_64.h +21 -0
@@ -106,9 +106,30 @@ static inline void native_pud_clear(pud_
 	native_set_pud(pud, native_make_pud(0));
 }
 
+#ifdef CONFIG_KAISER
+static inline pgd_t * native_get_shadow_pgd(pgd_t *pgdp) {
+	return (pgd_t *)(void*)((unsigned long)(void*)pgdp | (unsigned long)PAGE_SIZE);
+}
+
+static inline pgd_t * native_get_normal_pgd(pgd_t *pgdp) {
+	return (pgd_t *)(void*)((unsigned long)(void*)pgdp &  ~(unsigned long)PAGE_SIZE);
+}
+#endif /* CONFIG_KAISER */
+
 static inline void native_set_pgd(pgd_t *pgdp, pgd_t pgd)
 {
+#ifdef CONFIG_KAISER
+	// We know that a pgd is page aligned.
+	// Therefore the lower indices have to be mapped to user space.
+	// These pages are mapped to the shadow mapping.
+	if ((((unsigned long)pgdp) % PAGE_SIZE) < (PAGE_SIZE / 2)) {
+		native_get_shadow_pgd(pgdp)->pgd = pgd.pgd;
+	}
+
+	pgdp->pgd = pgd.pgd & ~_PAGE_USER;
+#else /* CONFIG_KAISER */
 	*pgdp = pgd;
+#endif
 }
 
 static inline void native_pgd_clear(pgd_t *pgd)
arch/x86/include/asm/pgtable_types.h +10 -2
@@ -39,7 +39,11 @@
 #define _PAGE_ACCESSED	(_AT(pteval_t, 1) << _PAGE_BIT_ACCESSED)
 #define _PAGE_DIRTY	(_AT(pteval_t, 1) << _PAGE_BIT_DIRTY)
 #define _PAGE_PSE	(_AT(pteval_t, 1) << _PAGE_BIT_PSE)
-#define _PAGE_GLOBAL	(_AT(pteval_t, 1) << _PAGE_BIT_GLOBAL)
+#ifdef CONFIG_KAISER
+#define _PAGE_GLOBAL	(_AT(pteval_t, 0))
+#else
+#define _PAGE_GLOBAL  (_AT(pteval_t, 1) << _PAGE_BIT_GLOBAL)
+#endif
 #define _PAGE_SOFTW1	(_AT(pteval_t, 1) << _PAGE_BIT_SOFTW1)
 #define _PAGE_SOFTW2	(_AT(pteval_t, 1) << _PAGE_BIT_SOFTW2)
 #define _PAGE_PAT	(_AT(pteval_t, 1) << _PAGE_BIT_PAT)
@@ -89,7 +93,11 @@
 #define _PAGE_NX	(_AT(pteval_t, 0))
 #endif
 
-#define _PAGE_PROTNONE	(_AT(pteval_t, 1) << _PAGE_BIT_PROTNONE)
+#ifdef CONFIG_KAISER
+#define _PAGE_PROTNONE	(_AT(pteval_t, 0))
+#else
+#define _PAGE_PROTNONE  (_AT(pteval_t, 1) << _PAGE_BIT_PROTNONE)
+#endif
 
 #define _PAGE_TABLE	(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER |	\
 			 _PAGE_ACCESSED | _PAGE_DIRTY)
arch/x86/include/asm/processor.h +6 -1
@@ -305,7 +305,7 @@ struct tss_struct {
 
 } ____cacheline_aligned;
 
-DECLARE_PER_CPU_SHARED_ALIGNED(struct tss_struct, cpu_tss);
+DECLARE_PER_CPU_SHARED_ALIGNED_USER_MAPPED(struct tss_struct, cpu_tss);
 
 #ifdef CONFIG_X86_32
 DECLARE_PER_CPU(unsigned long, cpu_current_top_of_stack);
@@ -332,6 +332,11 @@ union irq_stack_union {
 		char gs_base[40];
 		unsigned long stack_canary;
 	};
+
+	struct {
+		char irq_stack_pointer[64];
+		char unused[IRQ_STACK_SIZE - 64];
+	};
 };
 
 DECLARE_PER_CPU_FIRST(union irq_stack_union, irq_stack_union) __visible;
arch/x86/kernel/cpu/common.c +2 -2
@@ -92,7 +92,7 @@ static const struct cpu_dev default_cpu
 
 static const struct cpu_dev *this_cpu = &default_cpu;
 
-DEFINE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page) = { .gdt = {
+DEFINE_PER_CPU_PAGE_ALIGNED_USER_MAPPED(struct gdt_page, gdt_page) = { .gdt = {
 #ifdef CONFIG_X86_64
 	/*
 	 * We need valid kernel segments for data and code in long mode too
@@ -1229,7 +1229,7 @@ static const unsigned int exception_stac
 	  [DEBUG_STACK - 1]			= DEBUG_STKSZ
 };
 
-static DEFINE_PER_CPU_PAGE_ALIGNED(char, exception_stacks
+DEFINE_PER_CPU_PAGE_ALIGNED_USER_MAPPED(char, exception_stacks
 	[(N_EXCEPTION_STACKS - 1) * EXCEPTION_STKSZ + DEBUG_STKSZ]);
 
 /* May not be marked __init: used by software suspend */
arch/x86/kernel/espfix_64.c +6 -0
@@ -41,6 +41,7 @@
 #include <asm/pgalloc.h>
 #include <asm/setup.h>
 #include <asm/espfix.h>
+#include <asm/kaiser.h>
 
 /*
  * Note: we only need 6*8 = 48 bytes for the espfix stack, but round
@@ -126,6 +127,11 @@ void __init init_espfix_bsp(void)
 	/* Install the espfix pud into the kernel page directory */
 	pgd_p = &init_level4_pgt[pgd_index(ESPFIX_BASE_ADDR)];
 	pgd_populate(&init_mm, pgd_p, (pud_t *)espfix_pud_page);
+#ifdef CONFIG_KAISER
+	// add the esp stack pud to the shadow mapping here.
+	// This can be done directly, because the fixup stack has its own pud
+	set_pgd(native_get_shadow_pgd(pgd_p), __pgd(_PAGE_TABLE | __pa((pud_t *)espfix_pud_page)));
+#endif
 
 	/* Randomize the locations */
 	init_espfix_random();
arch/x86/kernel/head_64.S +12 -4
@@ -441,6 +441,14 @@ early_idt_ripmsg:
 	.balign	PAGE_SIZE; \
 GLOBAL(name)
 
+#ifdef CONFIG_KAISER
+#define NEXT_PGD_PAGE(name) \
+	.balign 2 * PAGE_SIZE; \
+GLOBAL(name)
+#else
+#define NEXT_PGD_PAGE(name) NEXT_PAGE(name)
+#endif
+
 /* Automate the creation of 1 to 1 mapping pmd entries */
 #define PMDS(START, PERM, COUNT)			\
 	i = 0 ;						\
@@ -450,7 +458,7 @@ GLOBAL(name)
 	.endr
 
 	__INITDATA
-NEXT_PAGE(early_level4_pgt)
+NEXT_PGD_PAGE(early_level4_pgt)
 	.fill	511,8,0
 	.quad	level3_kernel_pgt - __START_KERNEL_map + _PAGE_TABLE
 
@@ -460,10 +468,10 @@ NEXT_PAGE(early_dynamic_pgts)
 	.data
 
 #ifndef CONFIG_XEN
-NEXT_PAGE(init_level4_pgt)
-	.fill	512,8,0
+NEXT_PGD_PAGE(init_level4_pgt)
+	.fill	2*512,8,0
 #else
-NEXT_PAGE(init_level4_pgt)
+NEXT_PGD_PAGE(init_level4_pgt)
 	.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE
 	.org    init_level4_pgt + L4_PAGE_OFFSET*8, 0
 	.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE
arch/x86/kernel/irqinit.c +1 -1
@@ -51,7 +51,7 @@ static struct irqaction irq2 = {
 	.flags = IRQF_NO_THREAD,
 };
 
-DEFINE_PER_CPU(vector_irq_t, vector_irq) = {
+DEFINE_PER_CPU_USER_MAPPED(vector_irq_t, vector_irq) = {
 	[0 ... NR_VECTORS - 1] = VECTOR_UNUSED,
 };
 
arch/x86/kernel/process.c +1 -1
@@ -39,7 +39,7 @@
  * section. Since TSS's are completely CPU-local, we want them
  * on exact cacheline boundaries, to eliminate cacheline ping-pong.
  */
-__visible DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, cpu_tss) = {
+__visible DEFINE_PER_CPU_SHARED_ALIGNED_USER_MAPPED(struct tss_struct, cpu_tss) = {
 	.x86_tss = {
 		.sp0 = TOP_OF_INIT_STACK,
 #ifdef CONFIG_X86_32
arch/x86/mm/Makefile +1 -0
@@ -32,3 +32,4 @@ obj-$(CONFIG_ACPI_NUMA)		+= srat.o
 obj-$(CONFIG_NUMA_EMU)		+= numa_emulation.o
 
 obj-$(CONFIG_X86_INTEL_MPX)	+= mpx.o
+obj-$(CONFIG_KAISER)		+= kaiser.o
arch/x86/mm/kaiser.c new file +160 -0

160 lines not on this page · raw message

arch/x86/mm/pageattr.c +1 -1
@@ -829,7 +829,7 @@ static void unmap_pmd_range(pud_t *pud,
 			pud_clear(pud);
 }
 
-static void unmap_pud_range(pgd_t *pgd, unsigned long start, unsigned long end)
+void unmap_pud_range(pgd_t *pgd, unsigned long start, unsigned long end)
 {
 	pud_t *pud = pud_offset(pgd, start);
 
arch/x86/mm/pgtable.c +26 -0
@@ -342,12 +342,38 @@ static inline void _pgd_free(pgd_t *pgd)
 #else
 static inline pgd_t *_pgd_alloc(void)
 {
+#ifdef CONFIG_KAISER
+	// Instead of one PML4, we aquire two PML4s and, thus, an 8kb-aligned memory
+	// block. Therefore, we have to allocate at least 3 pages. However, the
+	// __get_free_pages returns us 4 pages. Hence, we store the base pointer at
+	// the beginning of the page of our 8kb-aligned memory block in order to
+	// correctly free it afterwars.
+
+	unsigned long pages = __get_free_pages(PGALLOC_GFP, get_order(4*PAGE_SIZE));
+
+	if(native_get_normal_pgd((pgd_t*) pages) == (pgd_t*) pages)
+	{
+		*((unsigned long*)(pages + 2 * PAGE_SIZE)) = pages;
+		return (pgd_t *) pages;
+	}
+	else
+	{
+		*((unsigned long*)(pages + 3 * PAGE_SIZE)) = pages;
+		return (pgd_t *) (pages + PAGE_SIZE);
+	}
+#else
 	return (pgd_t *)__get_free_page(PGALLOC_GFP);
+#endif
 }
 
 static inline void _pgd_free(pgd_t *pgd)
 {
+#ifdef CONFIG_KAISER
+  unsigned long pages = *((unsigned long*) ((char*) pgd + 2 * PAGE_SIZE));
+	free_pages(pages, get_order(4*PAGE_SIZE));
+#else
 	free_page((unsigned long)pgd);
+#endif
 }
 #endif /* CONFIG_X86_PAE */
 
include/asm-generic/vmlinux.lds.h +10 -1
@@ -725,7 +725,16 @@
  */
 #define PERCPU_INPUT(cacheline)						\
 	VMLINUX_SYMBOL(__per_cpu_start) = .;				\
-	*(.data..percpu..first)						\
+	\
+	VMLINUX_SYMBOL(__per_cpu_user_mapped_start) = .;        \
+	*(.data..percpu..first)           \
+	. = ALIGN(cacheline);           \
+	*(.data..percpu..user_mapped)            \
+	*(.data..percpu..user_mapped..shared_aligned)        \
+	. = ALIGN(PAGE_SIZE);           \
+	*(.data..percpu..user_mapped..page_aligned)          \
+	VMLINUX_SYMBOL(__per_cpu_user_mapped_end) = .;        \
+	\
 	. = ALIGN(PAGE_SIZE);						\
 	*(.data..percpu..page_aligned)					\
 	. = ALIGN(cacheline);						\
include/linux/percpu-defs.h +30 -0
@@ -35,6 +35,12 @@
 
 #endif
 
+#ifdef CONFIG_KAISER
+#define USER_MAPPED_SECTION "..user_mapped"
+#else
+#define USER_MAPPED_SECTION ""
+#endif
+
 /*
  * Base implementations of per-CPU variable declarations and definitions, where
  * the section in which the variable is to be placed is provided by the
@@ -115,6 +121,12 @@
 #define DEFINE_PER_CPU(type, name)					\
 	DEFINE_PER_CPU_SECTION(type, name, "")
 
+#define DECLARE_PER_CPU_USER_MAPPED(type, name)         \
+	DECLARE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION)
+
+#define DEFINE_PER_CPU_USER_MAPPED(type, name)          \
+	DEFINE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION)
+
 /*
  * Declaration/definition used for per-CPU variables that must come first in
  * the set of variables.
@@ -144,6 +156,14 @@
 	DEFINE_PER_CPU_SECTION(type, name, PER_CPU_SHARED_ALIGNED_SECTION) \
 	____cacheline_aligned_in_smp
 
+#define DECLARE_PER_CPU_SHARED_ALIGNED_USER_MAPPED(type, name)			\
+	DECLARE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION PER_CPU_SHARED_ALIGNED_SECTION) \
+	____cacheline_aligned_in_smp
+
+#define DEFINE_PER_CPU_SHARED_ALIGNED_USER_MAPPED(type, name)			\
+	DEFINE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION PER_CPU_SHARED_ALIGNED_SECTION) \
+	____cacheline_aligned_in_smp
+
 #define DECLARE_PER_CPU_ALIGNED(type, name)				\
 	DECLARE_PER_CPU_SECTION(type, name, PER_CPU_ALIGNED_SECTION)	\
 	____cacheline_aligned
@@ -162,6 +182,16 @@
 #define DEFINE_PER_CPU_PAGE_ALIGNED(type, name)				\
 	DEFINE_PER_CPU_SECTION(type, name, "..page_aligned")		\
 	__aligned(PAGE_SIZE)
+/*
+ * Declaration/definition used for per-CPU variables that must be page aligned and need to be mapped in user mode.
+ */
+#define DECLARE_PER_CPU_PAGE_ALIGNED_USER_MAPPED(type, name)      \
+  DECLARE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION"..page_aligned")   \
+  __aligned(PAGE_SIZE)
+
+#define DEFINE_PER_CPU_PAGE_ALIGNED_USER_MAPPED(type, name)       \
+  DEFINE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION"..page_aligned")    \
+  __aligned(PAGE_SIZE)
 
 /*
  * Declaration/definition used for per-CPU variables that must be read mostly.
init/main.c +6 -0
@@ -87,6 +87,9 @@
 #include <asm/setup.h>
 #include <asm/sections.h>
 #include <asm/cacheflush.h>
+#ifdef CONFIG_KAISER
+#include <asm/kaiser.h>
+#endif
 
 static int kernel_init(void *);
 
@@ -492,6 +495,9 @@ static void __init mm_init(void)
 	pgtable_init();
 	vmalloc_init();
 	ioremap_huge_init();
+#ifdef CONFIG_KAISER
+	kaiser_init();
+#endif
 }
 
 asmlinkage __visible void __init start_kernel(void)
kernel/fork.c +8 -0
@@ -167,8 +167,12 @@ static struct thread_info *alloc_thread_
 	return page ? page_address(page) : NULL;
 }
 
+extern void kaiser_remove_mapping(unsigned long start_addr, unsigned long size);
 static inline void free_thread_info(struct thread_info *ti)
 {
+#ifdef CONFIG_KAISER
+	kaiser_remove_mapping((unsigned long)ti, THREAD_SIZE);
+#endif
 	free_kmem_pages((unsigned long)ti, THREAD_SIZE_ORDER);
 }
 # else
@@ -331,6 +335,7 @@ void set_task_stack_end_magic(struct tas
 	*stackend = STACK_END_MAGIC;	/* for overflow detection */
 }
 
+extern void kaiser_add_mapping(unsigned long addr, unsigned long size, unsigned long flags);
 static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
 {
 	struct task_struct *tsk;
@@ -352,6 +357,9 @@ static struct task_struct *dup_task_stru
 		goto free_ti;
 
 	tsk->stack = ti;
+#ifdef CONFIG_KAISER
+	kaiser_add_mapping((unsigned long)tsk->stack, THREAD_SIZE, __PAGE_KERNEL);
+#endif
 #ifdef CONFIG_SECCOMP
 	/*
 	 * We must handle setting up seccomp filters once we're under
security/Kconfig +7 -0
@@ -30,6 +30,13 @@ config SECURITY
 	  model will be used.
 
 	  If you are unsure how to answer this question, answer N.
+config KAISER
+	bool "Remove the kernel mapping in user mode"
+	depends on X86_64
+	depends on !PARAVIRT
+	help
+	  This enforces a strict kernel and user space isolation in order to close
+	  hardware side channels on kernel address information.
 
 config SECURITYFS
 	bool "Enable the securityfs filesystem"
author maintainer
#3 lore raw

PATCH 3/37 kaiser: merged update

In reply to Greg Kroah-Hartman

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

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

From: Dave Hansen <[email protected]>

Merged fixes and cleanups, rebased to 4.4.89 tree (no 5-level paging).

---
 arch/x86/entry/entry_64.S            |  106 ++++++++++-
 arch/x86/include/asm/kaiser.h        |   43 ++--
 arch/x86/include/asm/pgtable.h       |   18 +
 arch/x86/include/asm/pgtable_64.h    |   48 ++++-
 arch/x86/include/asm/pgtable_types.h |    6 
 arch/x86/kernel/espfix_64.c          |   13 -
 arch/x86/kernel/head_64.S            |   19 +-
 arch/x86/kernel/ldt.c                |   27 ++
 arch/x86/kernel/tracepoint.c         |    2 
 arch/x86/mm/kaiser.c                 |  318 +++++++++++++++++++++++++----------
 arch/x86/mm/pageattr.c               |   63 +++++-
 arch/x86/mm/pgtable.c                |   40 +---
 include/linux/kaiser.h               |   26 ++
 kernel/fork.c                        |    9 
 security/Kconfig                     |    5 
 15 files changed, 553 insertions(+), 190 deletions(-)
 create mode 100644 include/linux/kaiser.h
arch/x86/entry/entry_64.S +93 -13
@@ -212,6 +212,13 @@ entry_SYSCALL_64_fastpath:
 	movq	RIP(%rsp), %rcx
 	movq	EFLAGS(%rsp), %r11
 	RESTORE_C_REGS_EXCEPT_RCX_R11
+	/*
+	 * This opens a window where we have a user CR3, but are
+	 * running in the kernel.  This makes using the CS
+	 * register useless for telling whether or not we need to
+	 * switch CR3 in NMIs.  Normal interrupts are OK because
+	 * they are off here.
+	 */
 	SWITCH_USER_CR3
 	movq	RSP(%rsp), %rsp
 	/*
@@ -350,11 +357,25 @@ GLOBAL(int_ret_from_sys_call)
 syscall_return_via_sysret:
 	/* rcx and r11 are already restored (see code above) */
 	RESTORE_C_REGS_EXCEPT_RCX_R11
+	/*
+	 * This opens a window where we have a user CR3, but are
+	 * running in the kernel.  This makes using the CS
+	 * register useless for telling whether or not we need to
+	 * switch CR3 in NMIs.  Normal interrupts are OK because
+	 * they are off here.
+	 */
 	SWITCH_USER_CR3
 	movq	RSP(%rsp), %rsp
 	USERGS_SYSRET64
 
 opportunistic_sysret_failed:
+	/*
+	 * This opens a window where we have a user CR3, but are
+	 * running in the kernel.  This makes using the CS
+	 * register useless for telling whether or not we need to
+	 * switch CR3 in NMIs.  Normal interrupts are OK because
+	 * they are off here.
+	 */
 	SWITCH_USER_CR3
 	SWAPGS
 	jmp	restore_c_regs_and_iret
@@ -1059,6 +1080,13 @@ ENTRY(error_entry)
 	cld
 	SAVE_C_REGS 8
 	SAVE_EXTRA_REGS 8
+	/*
+	 * error_entry() always returns with a kernel gsbase and
+	 * CR3.  We must also have a kernel CR3/gsbase before
+	 * calling TRACE_IRQS_*.  Just unconditionally switch to
+	 * the kernel CR3 here.
+	 */
+	SWITCH_KERNEL_CR3
 	xorl	%ebx, %ebx
 	testb	$3, CS+8(%rsp)
 	jz	.Lerror_kernelspace
@@ -1069,7 +1097,6 @@ ENTRY(error_entry)
 	 * from user mode due to an IRET fault.
 	 */
 	SWAPGS
-	SWITCH_KERNEL_CR3
 
 .Lerror_entry_from_usermode_after_swapgs:
 	/*
@@ -1122,7 +1149,7 @@ ENTRY(error_entry)
 	 * Switch to kernel gsbase:
 	 */
 	SWAPGS
-	SWITCH_KERNEL_CR3
+
 	/*
 	 * Pretend that the exception came from user mode: set up pt_regs
 	 * as if we faulted immediately after IRET and clear EBX so that
@@ -1222,7 +1249,10 @@ ENTRY(nmi)
 	 */
 
 	SWAPGS_UNSAFE_STACK
-	SWITCH_KERNEL_CR3_NO_STACK
+	/*
+	 * percpu variables are mapped with user CR3, so no need
+	 * to switch CR3 here.
+	 */
 	cld
 	movq	%rsp, %rdx
 	movq	PER_CPU_VAR(cpu_current_top_of_stack), %rsp
@@ -1256,14 +1286,33 @@ ENTRY(nmi)
 
 	movq	%rsp, %rdi
 	movq	$-1, %rsi
+#ifdef CONFIG_KAISER
+	/* Unconditionally use kernel CR3 for do_nmi() */
+	/* %rax is saved above, so OK to clobber here */
+	movq	%cr3, %rax
+	pushq	%rax
+#ifdef CONFIG_KAISER_REAL_SWITCH
+	andq	$(~0x1000), %rax
+#endif
+	movq	%rax, %cr3
+#endif
 	call	do_nmi
+	/*
+	 * Unconditionally restore CR3.  I know we return to
+	 * kernel code that needs user CR3, but do we ever return
+	 * to "user mode" where we need the kernel CR3?
+	 */
+#ifdef CONFIG_KAISER
+	popq	%rax
+	mov	%rax, %cr3
+#endif
 
 	/*
 	 * Return back to user mode.  We must *not* do the normal exit
-	 * work, because we don't want to enable interrupts.  Fortunately,
-	 * do_nmi doesn't modify pt_regs.
+	 * work, because we don't want to enable interrupts.  Do not
+	 * switch to user CR3: we might be going back to kernel code
+	 * that had a user CR3 set.
 	 */
-	SWITCH_USER_CR3
 	SWAPGS
 	jmp	restore_c_regs_and_iret
 
@@ -1459,23 +1508,54 @@ end_repeat_nmi:
 	ALLOC_PT_GPREGS_ON_STACK
 
 	/*
-	 * Use paranoid_entry to handle SWAPGS, but no need to use paranoid_exit
-	 * as we should not be calling schedule in NMI context.
-	 * Even with normal interrupts enabled. An NMI should not be
-	 * setting NEED_RESCHED or anything that normal interrupts and
-	 * exceptions might do.
+	 * Use the same approach as paranoid_entry to handle SWAPGS, but
+	 * without CR3 handling since we do that differently in NMIs.  No
+	 * need to use paranoid_exit as we should not be calling schedule
+	 * in NMI context.  Even with normal interrupts enabled. An NMI
+	 * should not be setting NEED_RESCHED or anything that normal
+	 * interrupts and exceptions might do.
 	 */
-	call	paranoid_entry
+	cld
+	SAVE_C_REGS
+	SAVE_EXTRA_REGS
+	movl	$1, %ebx
+	movl	$MSR_GS_BASE, %ecx
+	rdmsr
+	testl	%edx, %edx
+	js	1f				/* negative -> in kernel */
+	SWAPGS
+	xorl	%ebx, %ebx
+1:
+#ifdef CONFIG_KAISER
+	/* Unconditionally use kernel CR3 for do_nmi() */
+	/* %rax is saved above, so OK to clobber here */
+	movq	%cr3, %rax
+	pushq	%rax
+#ifdef CONFIG_KAISER_REAL_SWITCH
+	andq	$(~0x1000), %rax
+#endif
+	movq	%rax, %cr3
+#endif
 
 	/* paranoidentry do_nmi, 0; without TRACE_IRQS_OFF */
 	movq	%rsp, %rdi
+	addq	$8, %rdi /* point %rdi at ptregs, fixed up for CR3 */
 	movq	$-1, %rsi
 	call	do_nmi
+	/*
+	 * Unconditionally restore CR3.  We might be returning to
+	 * kernel code that needs user CR3, like just just before
+	 * a sysret.
+	 */
+#ifdef CONFIG_KAISER
+	popq	%rax
+	mov	%rax, %cr3
+#endif
 
 	testl	%ebx, %ebx			/* swapgs needed? */
 	jnz	nmi_restore
 nmi_swapgs:
-	SWITCH_USER_CR3_NO_STACK
+	/* We fixed up CR3 above, so no need to switch it here */
 	SWAPGS_UNSAFE_STACK
 nmi_restore:
 	RESTORE_EXTRA_REGS
arch/x86/include/asm/kaiser.h +26 -17

87 lines not on this page · raw message

arch/x86/include/asm/pgtable.h +15 -3
@@ -653,7 +653,17 @@ static inline pud_t *pud_offset(pgd_t *p
 
 static inline int pgd_bad(pgd_t pgd)
 {
-	return (pgd_flags(pgd) & ~_PAGE_USER) != _KERNPG_TABLE;
+	pgdval_t ignore_flags = _PAGE_USER;
+	/*
+	 * We set NX on KAISER pgds that map userspace memory so
+	 * that userspace can not meaningfully use the kernel
+	 * page table by accident; it will fault on the first
+	 * instruction it tries to run.  See native_set_pgd().
+	 */
+	if (IS_ENABLED(CONFIG_KAISER))
+		ignore_flags |= _PAGE_NX;
+
+	return (pgd_flags(pgd) & ~ignore_flags) != _KERNPG_TABLE;
 }
 
 static inline int pgd_none(pgd_t pgd)
@@ -857,8 +867,10 @@ static inline void clone_pgd_range(pgd_t
 {
        memcpy(dst, src, count * sizeof(pgd_t));
 #ifdef CONFIG_KAISER
-	// clone the shadow pgd part as well
-	memcpy(native_get_shadow_pgd(dst), native_get_shadow_pgd(src), count * sizeof(pgd_t));
+	/* Clone the shadow pgd part as well */
+	memcpy(native_get_shadow_pgd(dst),
+	       native_get_shadow_pgd(src),
+	       count * sizeof(pgd_t));
 #endif
 }
 
arch/x86/include/asm/pgtable_64.h +40 -8

66 lines not on this page · raw message

arch/x86/include/asm/pgtable_types.h +1 -5
@@ -42,7 +42,7 @@
 #ifdef CONFIG_KAISER
 #define _PAGE_GLOBAL	(_AT(pteval_t, 0))
 #else
-#define _PAGE_GLOBAL  (_AT(pteval_t, 1) << _PAGE_BIT_GLOBAL)
+#define _PAGE_GLOBAL	(_AT(pteval_t, 1) << _PAGE_BIT_GLOBAL)
 #endif
 #define _PAGE_SOFTW1	(_AT(pteval_t, 1) << _PAGE_BIT_SOFTW1)
 #define _PAGE_SOFTW2	(_AT(pteval_t, 1) << _PAGE_BIT_SOFTW2)
@@ -93,11 +93,7 @@
 #define _PAGE_NX	(_AT(pteval_t, 0))
 #endif
 
-#ifdef CONFIG_KAISER
-#define _PAGE_PROTNONE	(_AT(pteval_t, 0))
-#else
 #define _PAGE_PROTNONE  (_AT(pteval_t, 1) << _PAGE_BIT_PROTNONE)
-#endif
 
 #define _PAGE_TABLE	(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER |	\
 			 _PAGE_ACCESSED | _PAGE_DIRTY)
arch/x86/kernel/espfix_64.c +8 -5
@@ -127,11 +127,14 @@ void __init init_espfix_bsp(void)
 	/* Install the espfix pud into the kernel page directory */
 	pgd_p = &init_level4_pgt[pgd_index(ESPFIX_BASE_ADDR)];
 	pgd_populate(&init_mm, pgd_p, (pud_t *)espfix_pud_page);
-#ifdef CONFIG_KAISER
-	// add the esp stack pud to the shadow mapping here.
-	// This can be done directly, because the fixup stack has its own pud
-	set_pgd(native_get_shadow_pgd(pgd_p), __pgd(_PAGE_TABLE | __pa((pud_t *)espfix_pud_page)));
-#endif
+	/*
+	 * Just copy the top-level PGD that is mapping the espfix
+	 * area to ensure it is mapped into the shadow user page
+	 * tables.
+	 */
+	if (IS_ENABLED(CONFIG_KAISER))
+		set_pgd(native_get_shadow_pgd(pgd_p),
+			__pgd(_KERNPG_TABLE | __pa((pud_t *)espfix_pud_page)));
 
 	/* Randomize the locations */
 	init_espfix_random();
arch/x86/kernel/head_64.S +18 -1
@@ -442,11 +442,24 @@ early_idt_ripmsg:
 GLOBAL(name)
 
 #ifdef CONFIG_KAISER
+/*
+ * Each PGD needs to be 8k long and 8k aligned.  We do not
+ * ever go out to userspace with these, so we do not
+ * strictly *need* the second page, but this allows us to
+ * have a single set_pgd() implementation that does not
+ * need to worry about whether it has 4k or 8k to work
+ * with.
+ *
+ * This ensures PGDs are 8k long:
+ */
+#define KAISER_USER_PGD_FILL	512
+/* This ensures they are 8k-aligned: */
 #define NEXT_PGD_PAGE(name) \
 	.balign 2 * PAGE_SIZE; \
 GLOBAL(name)
 #else
 #define NEXT_PGD_PAGE(name) NEXT_PAGE(name)
+#define KAISER_USER_PGD_FILL	0
 #endif
 
 /* Automate the creation of 1 to 1 mapping pmd entries */
@@ -461,6 +474,7 @@ GLOBAL(name)
 NEXT_PGD_PAGE(early_level4_pgt)
 	.fill	511,8,0
 	.quad	level3_kernel_pgt - __START_KERNEL_map + _PAGE_TABLE
+	.fill	KAISER_USER_PGD_FILL,8,0
 
 NEXT_PAGE(early_dynamic_pgts)
 	.fill	512*EARLY_DYNAMIC_PAGE_TABLES,8,0
@@ -469,7 +483,8 @@ NEXT_PAGE(early_dynamic_pgts)
 
 #ifndef CONFIG_XEN
 NEXT_PGD_PAGE(init_level4_pgt)
-	.fill	2*512,8,0
+	.fill	512,8,0
+	.fill	KAISER_USER_PGD_FILL,8,0
 #else
 NEXT_PGD_PAGE(init_level4_pgt)
 	.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE
@@ -478,6 +493,7 @@ NEXT_PGD_PAGE(init_level4_pgt)
 	.org    init_level4_pgt + L4_START_KERNEL*8, 0
 	/* (2^48-(2*1024*1024*1024))/(2^39) = 511 */
 	.quad   level3_kernel_pgt - __START_KERNEL_map + _PAGE_TABLE
+	.fill	KAISER_USER_PGD_FILL,8,0
 
 NEXT_PAGE(level3_ident_pgt)
 	.quad	level2_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE
@@ -488,6 +504,7 @@ NEXT_PAGE(level2_ident_pgt)
 	 */
 	PMDS(0, __PAGE_KERNEL_IDENT_LARGE_EXEC, PTRS_PER_PMD)
 #endif
+	.fill	KAISER_USER_PGD_FILL,8,0
 
 NEXT_PAGE(level3_kernel_pgt)
 	.fill	L3_START_KERNEL,8,0
arch/x86/kernel/ldt.c +22 -5
@@ -18,6 +18,7 @@
 #include <linux/uaccess.h>
 
 #include <asm/ldt.h>
+#include <asm/kaiser.h>
 #include <asm/desc.h>
 #include <asm/mmu_context.h>
 #include <asm/syscalls.h>
@@ -34,11 +35,21 @@ static void flush_ldt(void *current_mm)
 	set_ldt(pc->ldt->entries, pc->ldt->size);
 }
 
+static void __free_ldt_struct(struct ldt_struct *ldt)
+{
+	if (ldt->size * LDT_ENTRY_SIZE > PAGE_SIZE)
+		vfree(ldt->entries);
+	else
+		free_page((unsigned long)ldt->entries);
+	kfree(ldt);
+}
+
 /* The caller must call finalize_ldt_struct on the result. LDT starts zeroed. */
 static struct ldt_struct *alloc_ldt_struct(int size)
 {
 	struct ldt_struct *new_ldt;
 	int alloc_size;
+	int ret = 0;
 
 	if (size > LDT_ENTRIES)
 		return NULL;
@@ -66,6 +77,14 @@ static struct ldt_struct *alloc_ldt_stru
 		return NULL;
 	}
 
+	// FIXME: make kaiser_add_mapping() return an error code
+	// when it fails
+	kaiser_add_mapping((unsigned long)new_ldt->entries, alloc_size,
+			   __PAGE_KERNEL);
+	if (ret) {
+		__free_ldt_struct(new_ldt);
+		return NULL;
+	}
 	new_ldt->size = size;
 	return new_ldt;
 }
@@ -92,12 +111,10 @@ static void free_ldt_struct(struct ldt_s
 	if (likely(!ldt))
 		return;
 
+	kaiser_remove_mapping((unsigned long)ldt->entries,
+			      ldt->size * LDT_ENTRY_SIZE);
 	paravirt_free_ldt(ldt->entries, ldt->size);
-	if (ldt->size * LDT_ENTRY_SIZE > PAGE_SIZE)
-		vfree(ldt->entries);
-	else
-		free_page((unsigned long)ldt->entries);
-	kfree(ldt);
+	__free_ldt_struct(ldt);
 }
 
 /*
arch/x86/kernel/tracepoint.c +2 -0
@@ -9,10 +9,12 @@
 #include <linux/atomic.h>
 
 atomic_t trace_idt_ctr = ATOMIC_INIT(0);
+__aligned(PAGE_SIZE)
 struct desc_ptr trace_idt_descr = { NR_VECTORS * 16 - 1,
 				(unsigned long) trace_idt_table };
 
 /* No need to be aligned, but done to keep all IDTs defined the same way. */
+__aligned(PAGE_SIZE)
 gate_desc trace_idt_table[NR_VECTORS] __page_aligned_bss;
 
 static int trace_irq_vector_refcount;
arch/x86/mm/kaiser.c +232 -86

392 lines not on this page · raw message

arch/x86/mm/pageattr.c +47 -16

160 lines not on this page · raw message

arch/x86/mm/pgtable.c +13 -27
@@ -340,40 +340,26 @@ static inline void _pgd_free(pgd_t *pgd)
 		kmem_cache_free(pgd_cache, pgd);
 }
 #else
-static inline pgd_t *_pgd_alloc(void)
-{
-#ifdef CONFIG_KAISER
-	// Instead of one PML4, we aquire two PML4s and, thus, an 8kb-aligned memory
-	// block. Therefore, we have to allocate at least 3 pages. However, the
-	// __get_free_pages returns us 4 pages. Hence, we store the base pointer at
-	// the beginning of the page of our 8kb-aligned memory block in order to
-	// correctly free it afterwars.
 
-	unsigned long pages = __get_free_pages(PGALLOC_GFP, get_order(4*PAGE_SIZE));
-
-	if(native_get_normal_pgd((pgd_t*) pages) == (pgd_t*) pages)
-	{
-		*((unsigned long*)(pages + 2 * PAGE_SIZE)) = pages;
-		return (pgd_t *) pages;
-	}
-	else
-	{
-		*((unsigned long*)(pages + 3 * PAGE_SIZE)) = pages;
-		return (pgd_t *) (pages + PAGE_SIZE);
-	}
+#ifdef CONFIG_KAISER
+/*
+ * Instead of one pmd, we aquire two pmds.  Being order-1, it is
+ * both 8k in size and 8k-aligned.  That lets us just flip bit 12
+ * in a pointer to swap between the two 4k halves.
+ */
+#define PGD_ALLOCATION_ORDER 1
 #else
-	return (pgd_t *)__get_free_page(PGALLOC_GFP);
+#define PGD_ALLOCATION_ORDER 0
 #endif
+
+static inline pgd_t *_pgd_alloc(void)
+{
+	return (pgd_t *)__get_free_pages(PGALLOC_GFP, PGD_ALLOCATION_ORDER);
 }
 
 static inline void _pgd_free(pgd_t *pgd)
 {
-#ifdef CONFIG_KAISER
-  unsigned long pages = *((unsigned long*) ((char*) pgd + 2 * PAGE_SIZE));
-	free_pages(pages, get_order(4*PAGE_SIZE));
-#else
-	free_page((unsigned long)pgd);
-#endif
+	free_pages((unsigned long)pgd, PGD_ALLOCATION_ORDER);
 }
 #endif /* CONFIG_X86_PAE */
 
include/linux/kaiser.h new file +26 -0
@@ -0,0 +1,26 @@
+#ifndef _INCLUDE_KAISER_H
+#define _INCLUDE_KAISER_H
+
+#ifdef CONFIG_KAISER
+#include <asm/kaiser.h>
+#else
+
+/*
+ * These stubs are used whenever CONFIG_KAISER is off, which
+ * includes architectures that support KAISER, but have it
+ * disabled.
+ */
+
+static inline void kaiser_init(void)
+{
+}
+static inline void kaiser_remove_mapping(unsigned long start, unsigned long size)
+{
+}
+static inline int kaiser_add_mapping(unsigned long addr, unsigned long size, unsigned long flags)
+{
+	return 0;
+}
+
+#endif /* !CONFIG_KAISER */
+#endif /* _INCLUDE_KAISER_H */
kernel/fork.c +5 -4
@@ -58,6 +58,7 @@
 #include <linux/tsacct_kern.h>
 #include <linux/cn_proc.h>
 #include <linux/freezer.h>
+#include <linux/kaiser.h>
 #include <linux/delayacct.h>
 #include <linux/taskstats_kern.h>
 #include <linux/random.h>
@@ -335,7 +336,6 @@ void set_task_stack_end_magic(struct tas
 	*stackend = STACK_END_MAGIC;	/* for overflow detection */
 }
 
-extern void kaiser_add_mapping(unsigned long addr, unsigned long size, unsigned long flags);
 static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
 {
 	struct task_struct *tsk;
@@ -357,9 +357,10 @@ static struct task_struct *dup_task_stru
 		goto free_ti;
 
 	tsk->stack = ti;
-#ifdef CONFIG_KAISER
-	kaiser_add_mapping((unsigned long)tsk->stack, THREAD_SIZE, __PAGE_KERNEL);
-#endif
+
+	err= kaiser_add_mapping((unsigned long)tsk->stack, THREAD_SIZE, __PAGE_KERNEL);
+	if (err)
+		goto free_ti;
 #ifdef CONFIG_SECCOMP
 	/*
 	 * We must handle setting up seccomp filters once we're under
security/Kconfig +5 -0
@@ -32,12 +32,17 @@ config SECURITY
 	  If you are unsure how to answer this question, answer N.
 config KAISER
 	bool "Remove the kernel mapping in user mode"
+	default y
 	depends on X86_64
 	depends on !PARAVIRT
 	help
 	  This enforces a strict kernel and user space isolation in order to close
 	  hardware side channels on kernel address information.
 
+config KAISER_REAL_SWITCH
+	bool "KAISER: actually switch page tables"
+	default y
+
 config SECURITYFS
 	bool "Enable the securityfs filesystem"
 	help
author maintainer
#4 lore raw

PATCH 4/37 kaiser: do not set _PAGE_NX on pgd_none

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

native_pgd_clear() uses native_set_pgd(), so native_set_pgd() must avoid setting the _PAGE_NX bit on an otherwise pgd_none() entry:
usually that just generated a warning on exit, but sometimes more mysterious and damaging failures (our production machines could not complete booting).

The original fix to this just avoided adding _PAGE_NX to an empty entry; but eventually more problems surfaced with kexec, and EFI mapping expected to be a problem too. So now instead change native_set_pgd() to update shadow only if _PAGE_USER:

A few places (kernel/machine_kexec_64.c, platform/efi/efi_64.c for sure) use set_pgd() to set up a temporary internal virtual address space, with physical pages remapped at what Kaiser regards as userspace addresses:
Kaiser then assumes a shadow pgd follows, which it will try to corrupt.

This appears to be responsible for the recent kexec and kdump failures; though it's unclear how those did not manifest as a problem before. Ah, the shadow pgd will only be assumed to "follow" if the requested pgd is on an even-numbered page: so I suppose it was going wrong 50% of the time all along.

What we need is a flag to set_pgd(), to tell it we're dealing with userspace. Er, isn't that what the pgd's _PAGE_USER bit is saying? Add a test for that. But we cannot do the same for pgd_clear() (which may be called to clear corrupted entries - set aside the question of "corrupt in which pgd?" until later), so there just rely on pgd_clear() not being called in the problematic cases - with a WARN_ON_ONCE() which should fire half the time if it is.

But this is getting too big for an inline function: move it into arch/x86/mm/kaiser.c (which then demands a boot/compressed mod); and de-void and de-space native_get_shadow/normal_pgd() while here.

---
 arch/x86/boot/compressed/misc.h   |    1 
 arch/x86/include/asm/pgtable_64.h |   51 +++++++++-----------------------------
 arch/x86/mm/kaiser.c              |   42 +++++++++++++++++++++++++++++++
 3 files changed, 56 insertions(+), 38 deletions(-)
arch/x86/boot/compressed/misc.h +1 -0
@@ -9,6 +9,7 @@
  */
 #undef CONFIG_PARAVIRT
 #undef CONFIG_PARAVIRT_SPINLOCKS
+#undef CONFIG_KAISER
 #undef CONFIG_KASAN
 
 #include <linux/linkage.h>
arch/x86/include/asm/pgtable_64.h +13 -38

74 lines not on this page · raw message

arch/x86/mm/kaiser.c +42 -0

46 lines not on this page · raw message

author maintainer
#5 lore raw

PATCH 5/37 kaiser: stack map PAGE_SIZE at THREAD_SIZE-PAGE_SIZE

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

Kaiser only needs to map one page of the stack; and kernel/fork.c did not build on powerpc (no __PAGE_KERNEL). It's all cleaner if linux/kaiser.h provides kaiser_map_thread_stack() and kaiser_unmap_thread_stack() wrappers around asm/kaiser.h's kaiser_add_mapping() and kaiser_remove_mapping(). And use linux/kaiser.h in init/main.c to avoid the #ifdefs there.

---
 include/linux/kaiser.h |   40 +++++++++++++++++++++++++++++++++-------
 init/main.c            |    6 +-----
 kernel/fork.c          |    7 ++-----
 3 files changed, 36 insertions(+), 17 deletions(-)
include/linux/kaiser.h +33 -7
@@ -1,26 +1,52 @@
-#ifndef _INCLUDE_KAISER_H
-#define _INCLUDE_KAISER_H
+#ifndef _LINUX_KAISER_H
+#define _LINUX_KAISER_H
 
 #ifdef CONFIG_KAISER
 #include <asm/kaiser.h>
+
+static inline int kaiser_map_thread_stack(void *stack)
+{
+	/*
+	 * Map that page of kernel stack on which we enter from user context.
+	 */
+	return kaiser_add_mapping((unsigned long)stack +
+			THREAD_SIZE - PAGE_SIZE, PAGE_SIZE, __PAGE_KERNEL);
+}
+
+static inline void kaiser_unmap_thread_stack(void *stack)
+{
+	/*
+	 * Note: may be called even when kaiser_map_thread_stack() failed.
+	 */
+	kaiser_remove_mapping((unsigned long)stack +
+			THREAD_SIZE - PAGE_SIZE, PAGE_SIZE);
+}
 #else
 
 /*
  * These stubs are used whenever CONFIG_KAISER is off, which
- * includes architectures that support KAISER, but have it
- * disabled.
+ * includes architectures that support KAISER, but have it disabled.
  */
 
 static inline void kaiser_init(void)
 {
 }
-static inline void kaiser_remove_mapping(unsigned long start, unsigned long size)
+static inline int kaiser_add_mapping(unsigned long addr,
+				     unsigned long size, unsigned long flags)
+{
+	return 0;
+}
+static inline void kaiser_remove_mapping(unsigned long start,
+					 unsigned long size)
 {
 }
-static inline int kaiser_add_mapping(unsigned long addr, unsigned long size, unsigned long flags)
+static inline int kaiser_map_thread_stack(void *stack)
 {
 	return 0;
 }
+static inline void kaiser_unmap_thread_stack(void *stack)
+{
+}
 
 #endif /* !CONFIG_KAISER */
-#endif /* _INCLUDE_KAISER_H */
+#endif /* _LINUX_KAISER_H */
init/main.c +1 -5
@@ -81,15 +81,13 @@
 #include <linux/integrity.h>
 #include <linux/proc_ns.h>
 #include <linux/io.h>
+#include <linux/kaiser.h>
 
 #include <asm/io.h>
 #include <asm/bugs.h>
 #include <asm/setup.h>
 #include <asm/sections.h>
 #include <asm/cacheflush.h>
-#ifdef CONFIG_KAISER
-#include <asm/kaiser.h>
-#endif
 
 static int kernel_init(void *);
 
@@ -495,9 +493,7 @@ static void __init mm_init(void)
 	pgtable_init();
 	vmalloc_init();
 	ioremap_huge_init();
-#ifdef CONFIG_KAISER
 	kaiser_init();
-#endif
 }
 
 asmlinkage __visible void __init start_kernel(void)
kernel/fork.c +2 -5
@@ -168,12 +168,9 @@ static struct thread_info *alloc_thread_
 	return page ? page_address(page) : NULL;
 }
 
-extern void kaiser_remove_mapping(unsigned long start_addr, unsigned long size);
 static inline void free_thread_info(struct thread_info *ti)
 {
-#ifdef CONFIG_KAISER
-	kaiser_remove_mapping((unsigned long)ti, THREAD_SIZE);
-#endif
+	kaiser_unmap_thread_stack(ti);
 	free_kmem_pages((unsigned long)ti, THREAD_SIZE_ORDER);
 }
 # else
@@ -358,7 +355,7 @@ static struct task_struct *dup_task_stru
 
 	tsk->stack = ti;
 
-	err= kaiser_add_mapping((unsigned long)tsk->stack, THREAD_SIZE, __PAGE_KERNEL);
+	err = kaiser_map_thread_stack(tsk->stack);
 	if (err)
 		goto free_ti;
 #ifdef CONFIG_SECCOMP
author maintainer
#6 lore raw

PATCH 6/37 kaiser: fix build and FIXME in alloc_ldt_struct()

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

Include linux/kaiser.h instead of asm/kaiser.h to build ldt.c without CONFIG_KAISER. kaiser_add_mapping() does already return an error code, so fix the FIXME.

---
 arch/x86/kernel/ldt.c |   10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)
arch/x86/kernel/ldt.c +4 -6
@@ -16,9 +16,9 @@
 #include <linux/slab.h>
 #include <linux/vmalloc.h>
 #include <linux/uaccess.h>
+#include <linux/kaiser.h>
 
 #include <asm/ldt.h>
-#include <asm/kaiser.h>
 #include <asm/desc.h>
 #include <asm/mmu_context.h>
 #include <asm/syscalls.h>
@@ -49,7 +49,7 @@ static struct ldt_struct *alloc_ldt_stru
 {
 	struct ldt_struct *new_ldt;
 	int alloc_size;
-	int ret = 0;
+	int ret;
 
 	if (size > LDT_ENTRIES)
 		return NULL;
@@ -77,10 +77,8 @@ static struct ldt_struct *alloc_ldt_stru
 		return NULL;
 	}
 
-	// FIXME: make kaiser_add_mapping() return an error code
-	// when it fails
-	kaiser_add_mapping((unsigned long)new_ldt->entries, alloc_size,
-			   __PAGE_KERNEL);
+	ret = kaiser_add_mapping((unsigned long)new_ldt->entries, alloc_size,
+				 __PAGE_KERNEL);
 	if (ret) {
 		__free_ldt_struct(new_ldt);
 		return NULL;
author maintainer
#7 lore raw

PATCH 7/37 kaiser: KAISER depends on SMP

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

It is absurd that KAISER should depend on SMP, but apparently nobody has tried a UP build before: which breaks on implicit declaration of function 'per_cpu_offset' in arch/x86/mm/kaiser.c.

Now, you would expect that to be trivially fixed up; but looking at the System.map when that block is #ifdef'ed out of kaiser_init(), I see that in a UP build __per_cpu_user_mapped_end is precisely at __per_cpu_user_mapped_start, and the items carefully gathered into that section for user-mapping on SMP, dispersed elsewhere on UP.

So, some other kind of section assignment will be needed on UP, but implementing that is not a priority: just make KAISER depend on SMP for now.

Also inserted a blank line before the option, tidied up the brief Kconfig help message, and added an "If unsure, Y".

---
 security/Kconfig |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
security/Kconfig +6 -4
@@ -30,14 +30,16 @@ config SECURITY
 	  model will be used.
 
 	  If you are unsure how to answer this question, answer N.
+
 config KAISER
 	bool "Remove the kernel mapping in user mode"
 	default y
-	depends on X86_64
-	depends on !PARAVIRT
+	depends on X86_64 && SMP && !PARAVIRT
 	help
-	  This enforces a strict kernel and user space isolation in order to close
-	  hardware side channels on kernel address information.
+	  This enforces a strict kernel and user space isolation, in order
+	  to close hardware side channels on kernel address information.
+
+	  If you are unsure how to answer this question, answer Y.
 
 config KAISER_REAL_SWITCH
 	bool "KAISER: actually switch page tables"
author maintainer
#8 lore raw

PATCH 8/37 kaiser: fix regs to do_nmi() ifndef CONFIG_KAISER

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

pjt has observed that nmi's second (nmi_from_kernel) call to do_nmi() adjusted the %rdi regs arg, rightly when CONFIG_KAISER, but wrongly when not CONFIG_KAISER.

Although the minimal change is to add an #ifdef CONFIG_KAISER around the addq line, that looks cluttered, and I prefer how the first call to do_nmi() handled it: prepare args in %rdi and %rsi before getting into the CONFIG_KAISER block, since it does not touch them at all.

And while we're here, place the "#ifdef CONFIG_KAISER" that follows each, to enclose the "Unconditionally restore CR3" comment: matching how the "Unconditionally use kernel CR3" comment above is enclosed.

---
 arch/x86/entry/entry_64.S |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
arch/x86/entry/entry_64.S +6 -5
@@ -1297,12 +1297,13 @@ ENTRY(nmi)
 	movq	%rax, %cr3
 #endif
 	call	do_nmi
+
+#ifdef CONFIG_KAISER
 	/*
 	 * Unconditionally restore CR3.  I know we return to
 	 * kernel code that needs user CR3, but do we ever return
 	 * to "user mode" where we need the kernel CR3?
 	 */
-#ifdef CONFIG_KAISER
 	popq	%rax
 	mov	%rax, %cr3
 #endif
@@ -1526,6 +1527,8 @@ end_repeat_nmi:
 	SWAPGS
 	xorl	%ebx, %ebx
 1:
+	movq	%rsp, %rdi
+	movq	$-1, %rsi
 #ifdef CONFIG_KAISER
 	/* Unconditionally use kernel CR3 for do_nmi() */
 	/* %rax is saved above, so OK to clobber here */
@@ -1538,16 +1541,14 @@ end_repeat_nmi:
 #endif
 
 	/* paranoidentry do_nmi, 0; without TRACE_IRQS_OFF */
-	movq	%rsp, %rdi
-	addq	$8, %rdi /* point %rdi at ptregs, fixed up for CR3 */
-	movq	$-1, %rsi
 	call	do_nmi
+
+#ifdef CONFIG_KAISER
 	/*
 	 * Unconditionally restore CR3.  We might be returning to
 	 * kernel code that needs user CR3, like just just before
 	 * a sysret.
 	 */
-#ifdef CONFIG_KAISER
 	popq	%rax
 	mov	%rax, %cr3
 #endif
author maintainer
#9 lore raw

PATCH 9/37 kaiser: fix perf crashes

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

Avoid perf crashes: place debug_store in the user-mapped per-cpu area instead of allocating, and use page allocator plus kaiser_add_mapping() to keep the BTS and PEBS buffers user-mapped (that is, present in the user mapping, though visible only to kernel and hardware). The PEBS fixup buffer does not need this treatment.

The need for a user-mapped struct debug_store showed up before doing any conscious perf testing: in a couple of kernel paging oopses on Westmere, implicating the debug_store offset of the per-cpu area.

---
 arch/x86/kernel/cpu/perf_event_intel_ds.c |   57 +++++++++++++++++++++++-------
 1 file changed, 45 insertions(+), 12 deletions(-)
arch/x86/kernel/cpu/perf_event_intel_ds.c +45 -12
@@ -2,11 +2,15 @@
 #include <linux/types.h>
 #include <linux/slab.h>
 
+#include <asm/kaiser.h>
 #include <asm/perf_event.h>
 #include <asm/insn.h>
 
 #include "perf_event.h"
 
+static
+DEFINE_PER_CPU_SHARED_ALIGNED_USER_MAPPED(struct debug_store, cpu_debug_store);
+
 /* The size of a BTS record in bytes: */
 #define BTS_RECORD_SIZE		24
 
@@ -268,6 +272,39 @@ void fini_debug_store_on_cpu(int cpu)
 
 static DEFINE_PER_CPU(void *, insn_buffer);
 
+static void *dsalloc(size_t size, gfp_t flags, int node)
+{
+#ifdef CONFIG_KAISER
+	unsigned int order = get_order(size);
+	struct page *page;
+	unsigned long addr;
+
+	page = __alloc_pages_node(node, flags | __GFP_ZERO, order);
+	if (!page)
+		return NULL;
+	addr = (unsigned long)page_address(page);
+	if (kaiser_add_mapping(addr, size, __PAGE_KERNEL) < 0) {
+		__free_pages(page, order);
+		addr = 0;
+	}
+	return (void *)addr;
+#else
+	return kmalloc_node(size, flags | __GFP_ZERO, node);
+#endif
+}
+
+static void dsfree(const void *buffer, size_t size)
+{
+#ifdef CONFIG_KAISER
+	if (!buffer)
+		return;
+	kaiser_remove_mapping((unsigned long)buffer, size);
+	free_pages((unsigned long)buffer, get_order(size));
+#else
+	kfree(buffer);
+#endif
+}
+
 static int alloc_pebs_buffer(int cpu)
 {
 	struct debug_store *ds = per_cpu(cpu_hw_events, cpu).ds;
@@ -278,7 +315,7 @@ static int alloc_pebs_buffer(int cpu)
 	if (!x86_pmu.pebs)
 		return 0;
 
-	buffer = kzalloc_node(x86_pmu.pebs_buffer_size, GFP_KERNEL, node);
+	buffer = dsalloc(x86_pmu.pebs_buffer_size, GFP_KERNEL, node);
 	if (unlikely(!buffer))
 		return -ENOMEM;
 
@@ -289,7 +326,7 @@ static int alloc_pebs_buffer(int cpu)
 	if (x86_pmu.intel_cap.pebs_format < 2) {
 		ibuffer = kzalloc_node(PEBS_FIXUP_SIZE, GFP_KERNEL, node);
 		if (!ibuffer) {
-			kfree(buffer);
+			dsfree(buffer, x86_pmu.pebs_buffer_size);
 			return -ENOMEM;
 		}
 		per_cpu(insn_buffer, cpu) = ibuffer;
@@ -315,7 +352,8 @@ static void release_pebs_buffer(int cpu)
 	kfree(per_cpu(insn_buffer, cpu));
 	per_cpu(insn_buffer, cpu) = NULL;
 
-	kfree((void *)(unsigned long)ds->pebs_buffer_base);
+	dsfree((void *)(unsigned long)ds->pebs_buffer_base,
+			x86_pmu.pebs_buffer_size);
 	ds->pebs_buffer_base = 0;
 }
 
@@ -329,7 +367,7 @@ static int alloc_bts_buffer(int cpu)
 	if (!x86_pmu.bts)
 		return 0;
 
-	buffer = kzalloc_node(BTS_BUFFER_SIZE, GFP_KERNEL | __GFP_NOWARN, node);
+	buffer = dsalloc(BTS_BUFFER_SIZE, GFP_KERNEL | __GFP_NOWARN, node);
 	if (unlikely(!buffer)) {
 		WARN_ONCE(1, "%s: BTS buffer allocation failure\n", __func__);
 		return -ENOMEM;
@@ -355,19 +393,15 @@ static void release_bts_buffer(int cpu)
 	if (!ds || !x86_pmu.bts)
 		return;
 
-	kfree((void *)(unsigned long)ds->bts_buffer_base);
+	dsfree((void *)(unsigned long)ds->bts_buffer_base, BTS_BUFFER_SIZE);
 	ds->bts_buffer_base = 0;
 }
 
 static int alloc_ds_buffer(int cpu)
 {
-	int node = cpu_to_node(cpu);
-	struct debug_store *ds;
-
-	ds = kzalloc_node(sizeof(*ds), GFP_KERNEL, node);
-	if (unlikely(!ds))
-		return -ENOMEM;
+	struct debug_store *ds = per_cpu_ptr(&cpu_debug_store, cpu);
 
+	memset(ds, 0, sizeof(*ds));
 	per_cpu(cpu_hw_events, cpu).ds = ds;
 
 	return 0;
@@ -381,7 +415,6 @@ static void release_ds_buffer(int cpu)
 		return;
 
 	per_cpu(cpu_hw_events, cpu).ds = NULL;
-	kfree(ds);
 }
 
 void release_ds_buffers(void)
author maintainer
#10 lore raw

PATCH 10/37 kaiser: ENOMEM if kaiser_pagetable_walk() NULL

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

kaiser_add_user_map() took no notice when kaiser_pagetable_walk() failed. And avoid its might_sleep() when atomic (though atomic at present unused).

---
 arch/x86/mm/kaiser.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)
arch/x86/mm/kaiser.c +7 -3
@@ -99,11 +99,11 @@ static pte_t *kaiser_pagetable_walk(unsi
 	pgd_t *pgd = native_get_shadow_pgd(pgd_offset_k(address));
 	gfp_t gfp = (GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO);
 
-	might_sleep();
 	if (is_atomic) {
 		gfp &= ~GFP_KERNEL;
 		gfp |= __GFP_HIGH | __GFP_ATOMIC;
-	}
+	} else
+		might_sleep();
 
 	if (pgd_none(*pgd)) {
 		WARN_ONCE(1, "All shadow pgds should have been populated");
@@ -160,13 +160,17 @@ int kaiser_add_user_map(const void *__st
 	unsigned long end_addr = PAGE_ALIGN(start_addr + size);
 	unsigned long target_address;
 
-	for (;address < end_addr; address += PAGE_SIZE) {
+	for (; address < end_addr; address += PAGE_SIZE) {
 		target_address = get_pa_from_mapping(address);
 		if (target_address == -1) {
 			ret = -EIO;
 			break;
 		}
 		pte = kaiser_pagetable_walk(address, false);
+		if (!pte) {
+			ret = -ENOMEM;
+			break;
+		}
 		if (pte_none(*pte)) {
 			set_pte(pte, __pte(flags | target_address));
 		} else {
author maintainer
#11 lore raw

PATCH 11/37 kaiser: tidied up asm/kaiser.h somewhat

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

Mainly deleting a surfeit of blank lines, and reflowing header comment.

---
 arch/x86/include/asm/kaiser.h |   32 +++++++++++++-------------------
 1 file changed, 13 insertions(+), 19 deletions(-)
arch/x86/include/asm/kaiser.h +13 -19
@@ -1,15 +1,17 @@
 #ifndef _ASM_X86_KAISER_H
 #define _ASM_X86_KAISER_H
-
-/* This file includes the definitions for the KAISER feature.
- * KAISER is a counter measure against x86_64 side channel attacks on the kernel virtual memory.
- * It has a shodow-pgd for every process. the shadow-pgd has a minimalistic kernel-set mapped,
- * but includes the whole user memory. Within a kernel context switch, or when an interrupt is handled,
- * the pgd is switched to the normal one. When the system switches to user mode, the shadow pgd is enabled.
- * By this, the virtual memory chaches are freed, and the user may not attack the whole kernel memory.
+/*
+ * This file includes the definitions for the KAISER feature.
+ * KAISER is a counter measure against x86_64 side channel attacks on
+ * the kernel virtual memory.  It has a shadow pgd for every process: the
+ * shadow pgd has a minimalistic kernel-set mapped, but includes the whole
+ * user memory. Within a kernel context switch, or when an interrupt is handled,
+ * the pgd is switched to the normal one. When the system switches to user mode,
+ * the shadow pgd is enabled. By this, the virtual memory caches are freed,
+ * and the user may not attack the whole kernel memory.
  *
- * A minimalistic kernel mapping holds the parts needed to be mapped in user mode, as the entry/exit functions
- * of the user space, or the stacks.
+ * A minimalistic kernel mapping holds the parts needed to be mapped in user
+ * mode, such as the entry/exit functions of the user space, or the stacks.
  */
 #ifdef __ASSEMBLY__
 #ifdef CONFIG_KAISER
@@ -48,13 +50,10 @@ _SWITCH_TO_KERNEL_CR3 %rax
 movq PER_CPU_VAR(unsafe_stack_register_backup), %rax
 .endm
 
-
 .macro SWITCH_USER_CR3_NO_STACK
-
 movq %rax, PER_CPU_VAR(unsafe_stack_register_backup)
 _SWITCH_TO_USER_CR3 %rax
 movq PER_CPU_VAR(unsafe_stack_register_backup), %rax
-
 .endm
 
 #else /* CONFIG_KAISER */
@@ -72,7 +71,6 @@ movq PER_CPU_VAR(unsafe_stack_register_b
 
 #else /* __ASSEMBLY__ */
 
-
 #ifdef CONFIG_KAISER
 /*
  * Upon kernel/user mode switch, it may happen that the address
@@ -80,7 +78,6 @@ movq PER_CPU_VAR(unsafe_stack_register_b
  * stored.  To change the address space, another register is
  * needed.  A register therefore has to be stored/restored.
 */
-
 DECLARE_PER_CPU_USER_MAPPED(unsigned long, unsafe_stack_register_backup);
 
 /**
@@ -95,7 +92,6 @@ DECLARE_PER_CPU_USER_MAPPED(unsigned lon
  */
 extern int kaiser_add_mapping(unsigned long addr, unsigned long size, unsigned long flags);
 
-
 /**
  *  kaiser_remove_mapping - unmap a virtual memory part of the shadow mapping
  *  @addr: the start address of the range
@@ -104,12 +100,12 @@ extern int kaiser_add_mapping(unsigned l
 extern void kaiser_remove_mapping(unsigned long start, unsigned long size);
 
 /**
- *  kaiser_initialize_mapping - Initalize the shadow mapping
+ *  kaiser_init - Initialize the shadow mapping
  *
  *  Most parts of the shadow mapping can be mapped upon boot
  *  time.  Only per-process things like the thread stacks
  *  or a new LDT have to be mapped at runtime.  These boot-
- *  time mappings are permanent and nevertunmapped.
+ *  time mappings are permanent and never unmapped.
  */
 extern void kaiser_init(void);
 
@@ -117,6 +113,4 @@ extern void kaiser_init(void);
 
 #endif /* __ASSEMBLY */
 
-
-
 #endif /* _ASM_X86_KAISER_H */
author maintainer
#12 lore raw

PATCH 12/37 kaiser: tidied up kaiser_add/remove_mapping slightly

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

Yes, unmap_pud_range_nofree()'s declaration ought to be in a header file really, but I'm not sure we want to use it anyway:
so for now just declare it inside kaiser_remove_mapping(). And there doesn't seem to be such a thing as unmap_p4d_range(), even in a 5-level paging tree.

---
 arch/x86/mm/kaiser.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)
arch/x86/mm/kaiser.c +3 -6
@@ -286,8 +286,7 @@ void __init kaiser_init(void)
 				  __PAGE_KERNEL);
 }
 
-extern void unmap_pud_range_nofree(pgd_t *pgd, unsigned long start, unsigned long end);
-// add a mapping to the shadow-mapping, and synchronize the mappings
+/* Add a mapping to the shadow mapping, and synchronize the mappings */
 int kaiser_add_mapping(unsigned long addr, unsigned long size, unsigned long flags)
 {
 	return kaiser_add_user_map((const void *)addr, size, flags);
@@ -295,15 +294,13 @@ int kaiser_add_mapping(unsigned long add
 
 void kaiser_remove_mapping(unsigned long start, unsigned long size)
 {
+	extern void unmap_pud_range_nofree(pgd_t *pgd,
+				unsigned long start, unsigned long end);
 	unsigned long end = start + size;
 	unsigned long addr;
 
 	for (addr = start; addr < end; addr += PGDIR_SIZE) {
 		pgd_t *pgd = native_get_shadow_pgd(pgd_offset_k(addr));
-		/*
-		 * unmap_p4d_range() handles > P4D_SIZE unmaps,
-		 * so no need to trim 'end'.
-		 */
 		unmap_pud_range_nofree(pgd, addr, end);
 	}
 }
author maintainer
#13 lore raw

PATCH 13/37 kaiser: kaiser_remove_mapping() move along the pgd

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

When removing the bogus comment from kaiser_remove_mapping(), I really ought to have checked the extent of its bogosity: as Neel points out, there is nothing to stop unmap_pud_range_nofree() from continuing beyond the end of a pud (and starting in the wrong position on the next).

Fix kaiser_remove_mapping() to constrain the extent and advance pgd pointer correctly: use pgd_addr_end() macro as used throughout base mm (but don't assume page-rounded start and size in this case).

But this bug was very unlikely to trigger in this backport: since any buddy allocation is contained within a single pud extent, and we are not using vmapped stacks (and are only mapping one page of stack anyway): the only way to hit this bug here would be when freeing a large modified ldt.

---
 arch/x86/mm/kaiser.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
arch/x86/mm/kaiser.c +6 -4
@@ -297,11 +297,13 @@ void kaiser_remove_mapping(unsigned long
 	extern void unmap_pud_range_nofree(pgd_t *pgd,
 				unsigned long start, unsigned long end);
 	unsigned long end = start + size;
-	unsigned long addr;
+	unsigned long addr, next;
+	pgd_t *pgd;
 
-	for (addr = start; addr < end; addr += PGDIR_SIZE) {
-		pgd_t *pgd = native_get_shadow_pgd(pgd_offset_k(addr));
-		unmap_pud_range_nofree(pgd, addr, end);
+	pgd = native_get_shadow_pgd(pgd_offset_k(start));
+	for (addr = start; addr < end; pgd++, addr = next) {
+		next = pgd_addr_end(addr, end);
+		unmap_pud_range_nofree(pgd, addr, next);
 	}
 }
 
author maintainer
#14 lore raw

PATCH 14/37 kaiser: cleanups while trying for gold link

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

While trying to get our gold link to work, four cleanups:
matched the gdt_page declaration to its definition;
in fiddling unsuccessfully with PERCPU_INPUT(), lined up backslashes; lined up the backslashes according to convention in percpu-defs.h; deleted the unused irq_stack_pointer addition to irq_stack_union.

Sad to report that aligning backslashes does not appear to help gold align to 8192: but while these did not help, they are worth keeping.

---
 arch/x86/include/asm/desc.h       |    2 +-
 arch/x86/include/asm/processor.h  |    5 -----
 include/asm-generic/vmlinux.lds.h |   18 ++++++++----------
 include/linux/percpu-defs.h       |   24 ++++++++++++------------
 4 files changed, 21 insertions(+), 28 deletions(-)
arch/x86/include/asm/desc.h +1 -1
@@ -43,7 +43,7 @@ struct gdt_page {
 	struct desc_struct gdt[GDT_ENTRIES];
 } __attribute__((aligned(PAGE_SIZE)));
 
-DECLARE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page);
+DECLARE_PER_CPU_PAGE_ALIGNED_USER_MAPPED(struct gdt_page, gdt_page);
 
 static inline struct desc_struct *get_cpu_gdt_table(unsigned int cpu)
 {
arch/x86/include/asm/processor.h +0 -5
@@ -332,11 +332,6 @@ union irq_stack_union {
 		char gs_base[40];
 		unsigned long stack_canary;
 	};
-
-	struct {
-		char irq_stack_pointer[64];
-		char unused[IRQ_STACK_SIZE - 64];
-	};
 };
 
 DECLARE_PER_CPU_FIRST(union irq_stack_union, irq_stack_union) __visible;
include/asm-generic/vmlinux.lds.h +8 -10
@@ -725,16 +725,14 @@
  */
 #define PERCPU_INPUT(cacheline)						\
 	VMLINUX_SYMBOL(__per_cpu_start) = .;				\
-	\
-	VMLINUX_SYMBOL(__per_cpu_user_mapped_start) = .;        \
-	*(.data..percpu..first)           \
-	. = ALIGN(cacheline);           \
-	*(.data..percpu..user_mapped)            \
-	*(.data..percpu..user_mapped..shared_aligned)        \
-	. = ALIGN(PAGE_SIZE);           \
-	*(.data..percpu..user_mapped..page_aligned)          \
-	VMLINUX_SYMBOL(__per_cpu_user_mapped_end) = .;        \
-	\
+	VMLINUX_SYMBOL(__per_cpu_user_mapped_start) = .;		\
+	*(.data..percpu..first)						\
+	. = ALIGN(cacheline);						\
+	*(.data..percpu..user_mapped)					\
+	*(.data..percpu..user_mapped..shared_aligned)			\
+	. = ALIGN(PAGE_SIZE);						\
+	*(.data..percpu..user_mapped..page_aligned)			\
+	VMLINUX_SYMBOL(__per_cpu_user_mapped_end) = .;			\
 	. = ALIGN(PAGE_SIZE);						\
 	*(.data..percpu..page_aligned)					\
 	. = ALIGN(cacheline);						\
include/linux/percpu-defs.h +12 -12
@@ -121,10 +121,10 @@
 #define DEFINE_PER_CPU(type, name)					\
 	DEFINE_PER_CPU_SECTION(type, name, "")
 
-#define DECLARE_PER_CPU_USER_MAPPED(type, name)         \
+#define DECLARE_PER_CPU_USER_MAPPED(type, name)				\
 	DECLARE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION)
 
-#define DEFINE_PER_CPU_USER_MAPPED(type, name)          \
+#define DEFINE_PER_CPU_USER_MAPPED(type, name)				\
 	DEFINE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION)
 
 /*
@@ -156,11 +156,11 @@
 	DEFINE_PER_CPU_SECTION(type, name, PER_CPU_SHARED_ALIGNED_SECTION) \
 	____cacheline_aligned_in_smp
 
-#define DECLARE_PER_CPU_SHARED_ALIGNED_USER_MAPPED(type, name)			\
+#define DECLARE_PER_CPU_SHARED_ALIGNED_USER_MAPPED(type, name)		\
 	DECLARE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION PER_CPU_SHARED_ALIGNED_SECTION) \
 	____cacheline_aligned_in_smp
 
-#define DEFINE_PER_CPU_SHARED_ALIGNED_USER_MAPPED(type, name)			\
+#define DEFINE_PER_CPU_SHARED_ALIGNED_USER_MAPPED(type, name)		\
 	DEFINE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION PER_CPU_SHARED_ALIGNED_SECTION) \
 	____cacheline_aligned_in_smp
 
@@ -185,18 +185,18 @@
 /*
  * Declaration/definition used for per-CPU variables that must be page aligned and need to be mapped in user mode.
  */
-#define DECLARE_PER_CPU_PAGE_ALIGNED_USER_MAPPED(type, name)      \
-  DECLARE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION"..page_aligned")   \
-  __aligned(PAGE_SIZE)
-
-#define DEFINE_PER_CPU_PAGE_ALIGNED_USER_MAPPED(type, name)       \
-  DEFINE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION"..page_aligned")    \
-  __aligned(PAGE_SIZE)
+#define DECLARE_PER_CPU_PAGE_ALIGNED_USER_MAPPED(type, name)		\
+	DECLARE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION"..page_aligned") \
+	__aligned(PAGE_SIZE)
+
+#define DEFINE_PER_CPU_PAGE_ALIGNED_USER_MAPPED(type, name)		\
+	DEFINE_PER_CPU_SECTION(type, name, USER_MAPPED_SECTION"..page_aligned") \
+	__aligned(PAGE_SIZE)
 
 /*
  * Declaration/definition used for per-CPU variables that must be read mostly.
  */
-#define DECLARE_PER_CPU_READ_MOSTLY(type, name)			\
+#define DECLARE_PER_CPU_READ_MOSTLY(type, name)				\
 	DECLARE_PER_CPU_SECTION(type, name, "..read_mostly")
 
 #define DEFINE_PER_CPU_READ_MOSTLY(type, name)				\
author maintainer
#15 lore raw

PATCH 15/37 kaiser: name that 0x1000 KAISER_SHADOW_PGD_OFFSET

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

There's a 0x1000 in various places, which looks better with a name.

---
 arch/x86/entry/entry_64.S     |    4 ++--
 arch/x86/include/asm/kaiser.h |    7 +++++--
 2 files changed, 7 insertions(+), 4 deletions(-)
arch/x86/entry/entry_64.S +2 -2
@@ -1292,7 +1292,7 @@ ENTRY(nmi)
 	movq	%cr3, %rax
 	pushq	%rax
 #ifdef CONFIG_KAISER_REAL_SWITCH
-	andq	$(~0x1000), %rax
+	andq	$(~KAISER_SHADOW_PGD_OFFSET), %rax
 #endif
 	movq	%rax, %cr3
 #endif
@@ -1535,7 +1535,7 @@ end_repeat_nmi:
 	movq	%cr3, %rax
 	pushq	%rax
 #ifdef CONFIG_KAISER_REAL_SWITCH
-	andq	$(~0x1000), %rax
+	andq	$(~KAISER_SHADOW_PGD_OFFSET), %rax
 #endif
 	movq	%rax, %cr3
 #endif
arch/x86/include/asm/kaiser.h +5 -2
@@ -13,13 +13,16 @@
  * A minimalistic kernel mapping holds the parts needed to be mapped in user
  * mode, such as the entry/exit functions of the user space, or the stacks.
  */
+
+#define KAISER_SHADOW_PGD_OFFSET 0x1000
+
 #ifdef __ASSEMBLY__
 #ifdef CONFIG_KAISER
 
 .macro _SWITCH_TO_KERNEL_CR3 reg
 movq %cr3, \reg
 #ifdef CONFIG_KAISER_REAL_SWITCH
-andq $(~0x1000), \reg
+andq $(~KAISER_SHADOW_PGD_OFFSET), \reg
 #endif
 movq \reg, %cr3
 .endm
@@ -27,7 +30,7 @@ movq \reg, %cr3
 .macro _SWITCH_TO_USER_CR3 reg
 movq %cr3, \reg
 #ifdef CONFIG_KAISER_REAL_SWITCH
-orq $(0x1000), \reg
+orq $(KAISER_SHADOW_PGD_OFFSET), \reg
 #endif
 movq \reg, %cr3
 .endm
author maintainer
#16 lore raw

PATCH 16/37 kaiser: delete KAISER_REAL_SWITCH option

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

We fail to see what CONFIG_KAISER_REAL_SWITCH is for: it seems to be left over from early development, and now just obscures tricky parts of the code. Delete it before adding PCIDs, or nokaiser boot option.

(Or if there is some good reason to keep the option, then it needs a help text - and a "depends on KAISER", so that all those without KAISER are not asked the question.)

---
 arch/x86/entry/entry_64.S     |    4 ----
 arch/x86/include/asm/kaiser.h |    4 ----
 security/Kconfig              |    4 ----
 3 files changed, 12 deletions(-)
arch/x86/entry/entry_64.S +0 -4
@@ -1291,9 +1291,7 @@ ENTRY(nmi)
 	/* %rax is saved above, so OK to clobber here */
 	movq	%cr3, %rax
 	pushq	%rax
-#ifdef CONFIG_KAISER_REAL_SWITCH
 	andq	$(~KAISER_SHADOW_PGD_OFFSET), %rax
-#endif
 	movq	%rax, %cr3
 #endif
 	call	do_nmi
@@ -1534,9 +1532,7 @@ end_repeat_nmi:
 	/* %rax is saved above, so OK to clobber here */
 	movq	%cr3, %rax
 	pushq	%rax
-#ifdef CONFIG_KAISER_REAL_SWITCH
 	andq	$(~KAISER_SHADOW_PGD_OFFSET), %rax
-#endif
 	movq	%rax, %cr3
 #endif
 
arch/x86/include/asm/kaiser.h +0 -4
@@ -21,17 +21,13 @@
 
 .macro _SWITCH_TO_KERNEL_CR3 reg
 movq %cr3, \reg
-#ifdef CONFIG_KAISER_REAL_SWITCH
 andq $(~KAISER_SHADOW_PGD_OFFSET), \reg
-#endif
 movq \reg, %cr3
 .endm
 
 .macro _SWITCH_TO_USER_CR3 reg
 movq %cr3, \reg
-#ifdef CONFIG_KAISER_REAL_SWITCH
 orq $(KAISER_SHADOW_PGD_OFFSET), \reg
-#endif
 movq \reg, %cr3
 .endm
 
security/Kconfig +0 -4
@@ -41,10 +41,6 @@ config KAISER
 
 	  If you are unsure how to answer this question, answer Y.
 
-config KAISER_REAL_SWITCH
-	bool "KAISER: actually switch page tables"
-	default y
-
 config SECURITYFS
 	bool "Enable the securityfs filesystem"
 	help
author maintainer
#17 lore raw

PATCH 17/37 kaiser: vmstat show NR_KAISERTABLE as nr_overhead

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

The kaiser update made an interesting choice, never to free any shadow page tables. Contention on global spinlock was worrying, particularly with it held across page table scans when freeing. Something had to be
done: I was going to add refcounting; but simply never to free them is an appealing choice, minimizing contention without complicating the code (the more a page table is found already, the less the spinlock is used).

But leaking pages in this way is also a worry: can we get away with it? At the very least, we need a count to show how bad it actually gets:
in principle, one might end up wasting about 1/256 of memory that way (1/512 for when direct-mapped pages have to be user-mapped, plus 1/512 for when they are user-mapped from the vmalloc area on another occasion (but we don't have vmalloc'ed stacks, so only large ldts are vmalloc'ed).

Add per-cpu stat NR_KAISERTABLE: including 256 at startup for the shared pgd entries, and 1 for each intermediate page table added thereafter for user-mapping - but leave out the 1 per mm, for its shadow pgd, because that distracts from the monotonic increase. Shown in /proc/vmstat as nr_overhead (0 if kaiser not enabled).

In practice, it doesn't look so bad so far: more like 1/12000 after nine hours of gtests below; and movable pageblock segregation should tend to cluster the kaiser tables into a subset of the address space (if not, they will be bad for compaction too). But production may tell a different story: keep an eye on this number, and bring back lighter freeing if it gets out of control (maybe a shrinker).

---
 arch/x86/mm/kaiser.c   |   16 +++++++++++-----
 include/linux/mmzone.h |    3 ++-
 mm/vmstat.c            |    1 +
 3 files changed, 14 insertions(+), 6 deletions(-)
arch/x86/mm/kaiser.c +11 -5
@@ -122,9 +122,11 @@ static pte_t *kaiser_pagetable_walk(unsi
 		if (!new_pmd_page)
 			return NULL;
 		spin_lock(&shadow_table_allocation_lock);
-		if (pud_none(*pud))
+		if (pud_none(*pud)) {
 			set_pud(pud, __pud(_KERNPG_TABLE | __pa(new_pmd_page)));
-		else
+			__inc_zone_page_state(virt_to_page((void *)
+						new_pmd_page), NR_KAISERTABLE);
+		} else
 			free_page(new_pmd_page);
 		spin_unlock(&shadow_table_allocation_lock);
 	}
@@ -140,9 +142,11 @@ static pte_t *kaiser_pagetable_walk(unsi
 		if (!new_pte_page)
 			return NULL;
 		spin_lock(&shadow_table_allocation_lock);
-		if (pmd_none(*pmd))
+		if (pmd_none(*pmd)) {
 			set_pmd(pmd, __pmd(_KERNPG_TABLE | __pa(new_pte_page)));
-		else
+			__inc_zone_page_state(virt_to_page((void *)
+						new_pte_page), NR_KAISERTABLE);
+		} else
 			free_page(new_pte_page);
 		spin_unlock(&shadow_table_allocation_lock);
 	}
@@ -206,11 +210,13 @@ static void __init kaiser_init_all_pgds(
 	pgd = native_get_shadow_pgd(pgd_offset_k((unsigned long )0));
 	for (i = PTRS_PER_PGD / 2; i < PTRS_PER_PGD; i++) {
 		pgd_t new_pgd;
-		pud_t *pud = pud_alloc_one(&init_mm, PAGE_OFFSET + i * PGDIR_SIZE);
+		pud_t *pud = pud_alloc_one(&init_mm,
+					   PAGE_OFFSET + i * PGDIR_SIZE);
 		if (!pud) {
 			WARN_ON(1);
 			break;
 		}
+		inc_zone_page_state(virt_to_page(pud), NR_KAISERTABLE);
 		new_pgd = __pgd(_KERNPG_TABLE |__pa(pud));
 		/*
 		 * Make sure not to stomp on some other pgd entry.
include/linux/mmzone.h +2 -1
@@ -131,8 +131,9 @@ enum zone_stat_item {
 	NR_SLAB_RECLAIMABLE,
 	NR_SLAB_UNRECLAIMABLE,
 	NR_PAGETABLE,		/* used for pagetables */
-	NR_KERNEL_STACK,
 	/* Second 128 byte cacheline */
+	NR_KERNEL_STACK,
+	NR_KAISERTABLE,
 	NR_UNSTABLE_NFS,	/* NFS unstable pages */
 	NR_BOUNCE,
 	NR_VMSCAN_WRITE,
mm/vmstat.c +1 -0
@@ -736,6 +736,7 @@ const char * const vmstat_text[] = {
 	"nr_slab_unreclaimable",
 	"nr_page_table_pages",
 	"nr_kernel_stack",
+	"nr_overhead",
 	"nr_unstable",
 	"nr_bounce",
 	"nr_vmscan_write",
author maintainer
#18 lore raw

PATCH 18/37 kaiser: enhanced by kernel and user PCIDs

In reply to Greg Kroah-Hartman

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

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

From: Dave Hansen <[email protected]>

Merged performance improvements to Kaiser, using distinct kernel and user Process Context Identifiers to minimize the TLB flushing.

---
 arch/x86/entry/entry_64.S                   |   10 ++++-
 arch/x86/entry/entry_64_compat.S            |    1 
 arch/x86/include/asm/cpufeature.h           |    1 
 arch/x86/include/asm/kaiser.h               |   15 ++++++-
 arch/x86/include/asm/pgtable_types.h        |   26 +++++++++++++
 arch/x86/include/asm/tlbflush.h             |   54 +++++++++++++++++++++++-----
 arch/x86/include/uapi/asm/processor-flags.h |    3 +
 arch/x86/kernel/cpu/common.c                |   34 +++++++++++++++++
 arch/x86/kvm/x86.c                          |    3 +
 arch/x86/mm/kaiser.c                        |    7 +++
 arch/x86/mm/tlb.c                           |   46 ++++++++++++++++++++++-
 11 files changed, 182 insertions(+), 18 deletions(-)
arch/x86/entry/entry_64.S +8 -2
@@ -1291,7 +1291,10 @@ ENTRY(nmi)
 	/* %rax is saved above, so OK to clobber here */
 	movq	%cr3, %rax
 	pushq	%rax
-	andq	$(~KAISER_SHADOW_PGD_OFFSET), %rax
+	/* mask off "user" bit of pgd address and 12 PCID bits: */
+	andq	$(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax
+	/* Add back kernel PCID and "no flush" bit */
+	orq	X86_CR3_PCID_KERN_VAR, %rax
 	movq	%rax, %cr3
 #endif
 	call	do_nmi
@@ -1532,7 +1535,10 @@ end_repeat_nmi:
 	/* %rax is saved above, so OK to clobber here */
 	movq	%cr3, %rax
 	pushq	%rax
-	andq	$(~KAISER_SHADOW_PGD_OFFSET), %rax
+	/* mask off "user" bit of pgd address and 12 PCID bits: */
+	andq	$(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax
+	/* Add back kernel PCID and "no flush" bit */
+	orq	X86_CR3_PCID_KERN_VAR, %rax
 	movq	%rax, %cr3
 #endif
 
arch/x86/entry/entry_64_compat.S +1 -0
@@ -13,6 +13,7 @@
 #include <asm/irqflags.h>
 #include <asm/asm.h>
 #include <asm/smap.h>
+#include <asm/pgtable_types.h>
 #include <asm/kaiser.h>
 #include <linux/linkage.h>
 #include <linux/err.h>
arch/x86/include/asm/cpufeature.h +1 -0
@@ -187,6 +187,7 @@
 #define X86_FEATURE_ARAT	( 7*32+ 1) /* Always Running APIC Timer */
 #define X86_FEATURE_CPB		( 7*32+ 2) /* AMD Core Performance Boost */
 #define X86_FEATURE_EPB		( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS support */
+#define X86_FEATURE_INVPCID_SINGLE ( 7*32+ 4) /* Effectively INVPCID && CR4.PCIDE=1 */
 #define X86_FEATURE_PLN		( 7*32+ 5) /* Intel Power Limit Notification */
 #define X86_FEATURE_PTS		( 7*32+ 6) /* Intel Package Thermal Status */
 #define X86_FEATURE_DTHERM	( 7*32+ 7) /* Digital Thermal Sensor */
arch/x86/include/asm/kaiser.h +13 -2
@@ -1,5 +1,8 @@
 #ifndef _ASM_X86_KAISER_H
 #define _ASM_X86_KAISER_H
+
+#include <uapi/asm/processor-flags.h> /* For PCID constants */
+
 /*
  * This file includes the definitions for the KAISER feature.
  * KAISER is a counter measure against x86_64 side channel attacks on
@@ -21,13 +24,21 @@
 
 .macro _SWITCH_TO_KERNEL_CR3 reg
 movq %cr3, \reg
-andq $(~KAISER_SHADOW_PGD_OFFSET), \reg
+andq $(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), \reg
+orq  X86_CR3_PCID_KERN_VAR, \reg
 movq \reg, %cr3
 .endm
 
 .macro _SWITCH_TO_USER_CR3 reg
 movq %cr3, \reg
-orq $(KAISER_SHADOW_PGD_OFFSET), \reg
+andq $(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), \reg
+/*
+ * This can obviously be one instruction by putting the
+ * KAISER_SHADOW_PGD_OFFSET bit in the X86_CR3_PCID_USER_VAR.
+ * But, just leave it now for simplicity.
+ */
+orq  X86_CR3_PCID_USER_VAR, \reg
+orq  $(KAISER_SHADOW_PGD_OFFSET), \reg
 movq \reg, %cr3
 .endm
 
arch/x86/include/asm/pgtable_types.h +26 -0
@@ -106,6 +106,32 @@
 			 _PAGE_SOFT_DIRTY)
 #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE)
 
+/* The ASID is the lower 12 bits of CR3 */
+#define X86_CR3_PCID_ASID_MASK  (_AC((1<<12)-1,UL))
+
+/* Mask for all the PCID-related bits in CR3: */
+#define X86_CR3_PCID_MASK       (X86_CR3_PCID_NOFLUSH | X86_CR3_PCID_ASID_MASK)
+#if defined(CONFIG_KAISER) && defined(CONFIG_X86_64)
+#define X86_CR3_PCID_ASID_KERN  (_AC(0x4,UL))
+#define X86_CR3_PCID_ASID_USER  (_AC(0x6,UL))
+
+#define X86_CR3_PCID_KERN_FLUSH		(X86_CR3_PCID_ASID_KERN)
+#define X86_CR3_PCID_USER_FLUSH		(X86_CR3_PCID_ASID_USER)
+#define X86_CR3_PCID_KERN_NOFLUSH	(X86_CR3_PCID_NOFLUSH | X86_CR3_PCID_ASID_KERN)
+#define X86_CR3_PCID_USER_NOFLUSH	(X86_CR3_PCID_NOFLUSH | X86_CR3_PCID_ASID_USER)
+#else
+#define X86_CR3_PCID_ASID_KERN  (_AC(0x0,UL))
+#define X86_CR3_PCID_ASID_USER  (_AC(0x0,UL))
+/*
+ * PCIDs are unsupported on 32-bit and none of these bits can be
+ * set in CR3:
+ */
+#define X86_CR3_PCID_KERN_FLUSH		(0)
+#define X86_CR3_PCID_USER_FLUSH		(0)
+#define X86_CR3_PCID_KERN_NOFLUSH	(0)
+#define X86_CR3_PCID_USER_NOFLUSH	(0)
+#endif
+
 /*
  * The cache modes defined here are used to translate between pure SW usage
  * and the HW defined cache mode bits and/or PAT entries.
arch/x86/include/asm/tlbflush.h +45 -9

79 lines not on this page · raw message

arch/x86/include/uapi/asm/processor-flags.h +2 -1
@@ -77,7 +77,8 @@
 #define X86_CR3_PWT		_BITUL(X86_CR3_PWT_BIT)
 #define X86_CR3_PCD_BIT		4 /* Page Cache Disable */
 #define X86_CR3_PCD		_BITUL(X86_CR3_PCD_BIT)
-#define X86_CR3_PCID_MASK	_AC(0x00000fff,UL) /* PCID Mask */
+#define X86_CR3_PCID_NOFLUSH_BIT 63 /* Preserve old PCID */
+#define X86_CR3_PCID_NOFLUSH    _BITULL(X86_CR3_PCID_NOFLUSH_BIT)
 
 /*
  * Intel CPU features in CR4
arch/x86/kernel/cpu/common.c +34 -0
@@ -321,11 +321,45 @@ static __always_inline void setup_smap(s
 	}
 }
 
+/*
+ * These can have bit 63 set, so we can not just use a plain "or"
+ * instruction to get their value or'd into CR3.  It would take
+ * another register.  So, we use a memory reference to these
+ * instead.
+ *
+ * This is also handy because systems that do not support
+ * PCIDs just end up or'ing a 0 into their CR3, which does
+ * no harm.
+ */
+__aligned(PAGE_SIZE) unsigned long X86_CR3_PCID_KERN_VAR = 0;
+__aligned(PAGE_SIZE) unsigned long X86_CR3_PCID_USER_VAR = 0;
+
 static void setup_pcid(struct cpuinfo_x86 *c)
 {
 	if (cpu_has(c, X86_FEATURE_PCID)) {
 		if (cpu_has(c, X86_FEATURE_PGE)) {
 			cr4_set_bits(X86_CR4_PCIDE);
+			/*
+			 * These variables are used by the entry/exit
+			 * code to change PCIDs.
+			 */
+#ifdef CONFIG_KAISER
+			X86_CR3_PCID_KERN_VAR = X86_CR3_PCID_KERN_NOFLUSH;
+			X86_CR3_PCID_USER_VAR = X86_CR3_PCID_USER_NOFLUSH;
+#endif
+			/*
+			 * INVPCID has two "groups" of types:
+			 * 1/2: Invalidate an individual address
+			 * 3/4: Invalidate all contexts
+			 *
+			 * 1/2 take a PCID, but 3/4 do not.  So, 3/4
+			 * ignore the PCID argument in the descriptor.
+			 * But, we have to be careful not to call 1/2
+			 * with an actual non-zero PCID in them before
+			 * we do the above cr4_set_bits().
+			 */
+			if (cpu_has(c, X86_FEATURE_INVPCID))
+				set_cpu_cap(c, X86_FEATURE_INVPCID_SINGLE);
 		} else {
 			/*
 			 * flush_tlb_all(), as currently implemented, won't
arch/x86/kvm/x86.c +2 -1
@@ -759,7 +759,8 @@ int kvm_set_cr4(struct kvm_vcpu *vcpu, u
 			return 1;
 
 		/* PCID can not be enabled when cr3[11:0]!=000H or EFER.LMA=0 */
-		if ((kvm_read_cr3(vcpu) & X86_CR3_PCID_MASK) || !is_long_mode(vcpu))
+		if ((kvm_read_cr3(vcpu) & X86_CR3_PCID_ASID_MASK) ||
+		    !is_long_mode(vcpu))
 			return 1;
 	}
 
arch/x86/mm/kaiser.c +7 -0
@@ -240,6 +240,8 @@ static void __init kaiser_init_all_pgds(
 } while (0)
 
 extern char __per_cpu_user_mapped_start[], __per_cpu_user_mapped_end[];
+extern unsigned long X86_CR3_PCID_KERN_VAR;
+extern unsigned long X86_CR3_PCID_USER_VAR;
 /*
  * If anything in here fails, we will likely die on one of the
  * first kernel->user transitions and init will die.  But, we
@@ -290,6 +292,11 @@ void __init kaiser_init(void)
 	kaiser_add_user_map_early(&debug_idt_table,
 				  sizeof(gate_desc) * NR_VECTORS,
 				  __PAGE_KERNEL);
+
+	kaiser_add_user_map_early(&X86_CR3_PCID_KERN_VAR, PAGE_SIZE,
+				  __PAGE_KERNEL);
+	kaiser_add_user_map_early(&X86_CR3_PCID_USER_VAR, PAGE_SIZE,
+				  __PAGE_KERNEL);
 }
 
 /* Add a mapping to the shadow mapping, and synchronize the mappings */
arch/x86/mm/tlb.c +43 -3

70 lines not on this page · raw message

author maintainer
#19 lore raw

PATCH 19/37 kaiser: load_new_mm_cr3() let SWITCH_USER_CR3 flush user

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

We have many machines (Westmere, Sandybridge, Ivybridge) supporting PCID but not INVPCID: on these load_new_mm_cr3() simply crashed.

Flushing user context inside load_new_mm_cr3() without the use of invpcid is difficult: momentarily switch from kernel to user context and back to do so? I'm not sure whether that can be safely done at all, and would risk polluting user context with kernel internals, and kernel context with stale user externals.

Instead, follow the hint in the comment that was there: change X86_CR3_PCID_USER_VAR to be a per-cpu variable, then load_new_mm_cr3() can leave a note in it, for SWITCH_USER_CR3 on return to userspace to flush user context TLB, instead of default X86_CR3_PCID_USER_NOFLUSH.

Which works well enough that there's no need to do it this way only when invpcid is unsupported: it's a good alternative to invpcid here. But there's a couple of inlines in asm/tlbflush.h that need to do the same trick, so it's best to localize all this per-cpu business in mm/kaiser.c: moving that part of the initialization from setup_pcid() to kaiser_setup_pcid(); with kaiser_flush_tlb_on_return_to_user() the function for noting an X86_CR3_PCID_USER_FLUSH. And let's keep a KAISER_SHADOW_PGD_OFFSET in there, to avoid the extra OR on exit.

I did try to make the feature tests in asm/tlbflush.h more consistent with each other: there seem to be far too many ways of performing such tests, and I don't have a good grasp of their differences. At first I converted them all to be static_cpu_has(): but that proved to be a mistake, as the comment in __native_flush_tlb_single() hints; so then I reversed and made them all this_cpu_has(). Probably all gratuitous change, but that's the way it's working at present.

I am slightly bothered by the way non-per-cpu X86_CR3_PCID_KERN_VAR gets re-initialized by each cpu (before and after these changes):
no problem when (as usual) all cpus on a machine have the same features, but in principle incorrect. However, my experiment to per-cpu-ify that one did not end well...

---
 arch/x86/include/asm/kaiser.h   |   18 +++++++-----
 arch/x86/include/asm/tlbflush.h |   58 +++++++++++++++++++++++++++-------------
 arch/x86/kernel/cpu/common.c    |   22 ---------------
 arch/x86/mm/kaiser.c            |   50 ++++++++++++++++++++++++++++++----
 arch/x86/mm/tlb.c               |   46 ++++++++++++-------------------
 5 files changed, 114 insertions(+), 80 deletions(-)
arch/x86/include/asm/kaiser.h +11 -7
@@ -32,13 +32,12 @@ movq \reg, %cr3
 .macro _SWITCH_TO_USER_CR3 reg
 movq %cr3, \reg
 andq $(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), \reg
-/*
- * This can obviously be one instruction by putting the
- * KAISER_SHADOW_PGD_OFFSET bit in the X86_CR3_PCID_USER_VAR.
- * But, just leave it now for simplicity.
- */
-orq  X86_CR3_PCID_USER_VAR, \reg
-orq  $(KAISER_SHADOW_PGD_OFFSET), \reg
+orq  PER_CPU_VAR(X86_CR3_PCID_USER_VAR), \reg
+js   9f
+// FLUSH this time, reset to NOFLUSH for next time
+// But if nopcid?  Consider using 0x80 for user pcid?
+movb $(0x80), PER_CPU_VAR(X86_CR3_PCID_USER_VAR+7)
+9:
 movq \reg, %cr3
 .endm
 
@@ -90,6 +89,11 @@ movq PER_CPU_VAR(unsafe_stack_register_b
 */
 DECLARE_PER_CPU_USER_MAPPED(unsigned long, unsafe_stack_register_backup);
 
+extern unsigned long X86_CR3_PCID_KERN_VAR;
+DECLARE_PER_CPU(unsigned long, X86_CR3_PCID_USER_VAR);
+
+extern char __per_cpu_user_mapped_start[], __per_cpu_user_mapped_end[];
+
 /**
  *  kaiser_add_mapping - map a virtual memory part to the shadow (user) mapping
  *  @addr: the start address of the range
arch/x86/include/asm/tlbflush.h +40 -18

101 lines not on this page · raw message

arch/x86/kernel/cpu/common.c +1 -21
@@ -321,33 +321,12 @@ static __always_inline void setup_smap(s
 	}
 }
 
-/*
- * These can have bit 63 set, so we can not just use a plain "or"
- * instruction to get their value or'd into CR3.  It would take
- * another register.  So, we use a memory reference to these
- * instead.
- *
- * This is also handy because systems that do not support
- * PCIDs just end up or'ing a 0 into their CR3, which does
- * no harm.
- */
-__aligned(PAGE_SIZE) unsigned long X86_CR3_PCID_KERN_VAR = 0;
-__aligned(PAGE_SIZE) unsigned long X86_CR3_PCID_USER_VAR = 0;
-
 static void setup_pcid(struct cpuinfo_x86 *c)
 {
 	if (cpu_has(c, X86_FEATURE_PCID)) {
 		if (cpu_has(c, X86_FEATURE_PGE)) {
 			cr4_set_bits(X86_CR4_PCIDE);
 			/*
-			 * These variables are used by the entry/exit
-			 * code to change PCIDs.
-			 */
-#ifdef CONFIG_KAISER
-			X86_CR3_PCID_KERN_VAR = X86_CR3_PCID_KERN_NOFLUSH;
-			X86_CR3_PCID_USER_VAR = X86_CR3_PCID_USER_NOFLUSH;
-#endif
-			/*
 			 * INVPCID has two "groups" of types:
 			 * 1/2: Invalidate an individual address
 			 * 3/4: Invalidate all contexts
@@ -372,6 +351,7 @@ static void setup_pcid(struct cpuinfo_x8
 			clear_cpu_cap(c, X86_FEATURE_PCID);
 		}
 	}
+	kaiser_setup_pcid();
 }
 
 /*
arch/x86/mm/kaiser.c +44 -6

77 lines not on this page · raw message

arch/x86/mm/tlb.c +18 -28

65 lines not on this page · raw message

author maintainer
#20 lore raw

PATCH 20/37 kaiser: PCID 0 for kernel and 128 for user

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

Why was 4 chosen for kernel PCID and 6 for user PCID? No good reason in a backport where PCIDs are only used for Kaiser.

If we continue with those, then we shall need to add Andy Lutomirski's 4.13 commit 6c690ee1039b ("x86/mm: Split read_cr3() into read_cr3_pa() and __read_cr3()"), which deals with the problem of read_cr3() callers finding stray bits in the cr3 that they expected to be page-aligned; and for hibernation, his 4.14 commit f34902c5c6c0 ("x86/hibernate/64:
Mask off CR3's PCID bits in the saved CR3").

But if 0 is used for kernel PCID, then there's no need to add in those commits - whenever the kernel looks, it sees 0 in the lower bits; and 0 for kernel seems an obvious choice.

And I naughtily propose 128 for user PCID. Because there's a place in _SWITCH_TO_USER_CR3 where it takes note of the need for TLB FLUSH, but needs to reset that to NOFLUSH for the next occasion. Currently it does so with a "movb $(0x80)" into the high byte of the per-cpu quadword, but that will cause a machine without PCID support to crash. Now, if %al just happened to have 0x80 in it at that point, on a machine with PCID support, but 0 on a machine without PCID support...

(That will go badly wrong once the pgd can be at a physical address above 2^56, but even with 5-level paging, physical goes up to 2^52.)

---
 arch/x86/include/asm/kaiser.h        |   19 ++++++++++++-------
 arch/x86/include/asm/pgtable_types.h |    7 ++++---
 arch/x86/mm/tlb.c                    |    3 +++
 3 files changed, 19 insertions(+), 10 deletions(-)
arch/x86/include/asm/kaiser.h +12 -7
@@ -29,14 +29,19 @@ orq  X86_CR3_PCID_KERN_VAR, \reg
 movq \reg, %cr3
 .endm
 
-.macro _SWITCH_TO_USER_CR3 reg
+.macro _SWITCH_TO_USER_CR3 reg regb
+/*
+ * regb must be the low byte portion of reg: because we have arranged
+ * for the low byte of the user PCID to serve as the high byte of NOFLUSH
+ * (0x80 for each when PCID is enabled, or 0x00 when PCID and NOFLUSH are
+ * not enabled): so that the one register can update both memory and cr3.
+ */
 movq %cr3, \reg
 andq $(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), \reg
 orq  PER_CPU_VAR(X86_CR3_PCID_USER_VAR), \reg
 js   9f
-// FLUSH this time, reset to NOFLUSH for next time
-// But if nopcid?  Consider using 0x80 for user pcid?
-movb $(0x80), PER_CPU_VAR(X86_CR3_PCID_USER_VAR+7)
+/* FLUSH this time, reset to NOFLUSH for next time (if PCID enabled) */
+movb \regb, PER_CPU_VAR(X86_CR3_PCID_USER_VAR+7)
 9:
 movq \reg, %cr3
 .endm
@@ -49,7 +54,7 @@ popq %rax
 
 .macro SWITCH_USER_CR3
 pushq %rax
-_SWITCH_TO_USER_CR3 %rax
+_SWITCH_TO_USER_CR3 %rax %al
 popq %rax
 .endm
 
@@ -61,7 +66,7 @@ movq PER_CPU_VAR(unsafe_stack_register_b
 
 .macro SWITCH_USER_CR3_NO_STACK
 movq %rax, PER_CPU_VAR(unsafe_stack_register_backup)
-_SWITCH_TO_USER_CR3 %rax
+_SWITCH_TO_USER_CR3 %rax %al
 movq PER_CPU_VAR(unsafe_stack_register_backup), %rax
 .endm
 
@@ -69,7 +74,7 @@ movq PER_CPU_VAR(unsafe_stack_register_b
 
 .macro SWITCH_KERNEL_CR3 reg
 .endm
-.macro SWITCH_USER_CR3 reg
+.macro SWITCH_USER_CR3 reg regb
 .endm
 .macro SWITCH_USER_CR3_NO_STACK
 .endm
arch/x86/include/asm/pgtable_types.h +4 -3
@@ -111,16 +111,17 @@
 
 /* Mask for all the PCID-related bits in CR3: */
 #define X86_CR3_PCID_MASK       (X86_CR3_PCID_NOFLUSH | X86_CR3_PCID_ASID_MASK)
+#define X86_CR3_PCID_ASID_KERN  (_AC(0x0,UL))
+
 #if defined(CONFIG_KAISER) && defined(CONFIG_X86_64)
-#define X86_CR3_PCID_ASID_KERN  (_AC(0x4,UL))
-#define X86_CR3_PCID_ASID_USER  (_AC(0x6,UL))
+/* Let X86_CR3_PCID_ASID_USER be usable for the X86_CR3_PCID_NOFLUSH bit */
+#define X86_CR3_PCID_ASID_USER	(_AC(0x80,UL))
 
 #define X86_CR3_PCID_KERN_FLUSH		(X86_CR3_PCID_ASID_KERN)
 #define X86_CR3_PCID_USER_FLUSH		(X86_CR3_PCID_ASID_USER)
 #define X86_CR3_PCID_KERN_NOFLUSH	(X86_CR3_PCID_NOFLUSH | X86_CR3_PCID_ASID_KERN)
 #define X86_CR3_PCID_USER_NOFLUSH	(X86_CR3_PCID_NOFLUSH | X86_CR3_PCID_ASID_USER)
 #else
-#define X86_CR3_PCID_ASID_KERN  (_AC(0x0,UL))
 #define X86_CR3_PCID_ASID_USER  (_AC(0x0,UL))
 /*
  * PCIDs are unsupported on 32-bit and none of these bits can be
arch/x86/mm/tlb.c +3 -0
@@ -50,6 +50,9 @@ static void load_new_mm_cr3(pgd_t *pgdir
 		 * invpcid_flush_single_context(X86_CR3_PCID_ASID_USER) could
 		 * do it here, but can only be used if X86_FEATURE_INVPCID is
 		 * available - and many machines support pcid without invpcid.
+		 *
+		 * The line below is a no-op: X86_CR3_PCID_KERN_FLUSH is now 0;
+		 * but keep that line in there in case something changes.
 		 */
 		new_mm_cr3 |= X86_CR3_PCID_KERN_FLUSH;
 		kaiser_flush_tlb_on_return_to_user();
author maintainer
#21 lore raw

PATCH 21/37 kaiser: x86_cr3_pcid_noflush and x86_cr3_pcid_user

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

Mostly this commit is just unshouting X86_CR3_PCID_KERN_VAR and
X86_CR3_PCID_USER_VAR: we usually name variables in lower-case.

But why does x86_cr3_pcid_noflush need to be __aligned(PAGE_SIZE)? Ah, it's a leftover from when kaiser_add_user_map() once complained about mapping the same page twice. Make it __read_mostly instead. (I'm a little uneasy about all the unrelated data which shares its page getting user-mapped too, but that was so before, and not a big
deal: though we call it user-mapped, it's not mapped with _PAGE_USER.)

And there is a little change around the two calls to do_nmi(). Previously they set the NOFLUSH bit (if PCID supported) when forcing to kernel context before do_nmi(); now they also have the NOFLUSH bit set (if PCID supported) when restoring context after:
nothing done in do_nmi() should require a TLB to be flushed here.

---
 arch/x86/entry/entry_64.S     |    8 ++++----
 arch/x86/include/asm/kaiser.h |   11 +++++------
 arch/x86/mm/kaiser.c          |   13 +++++++------
 3 files changed, 16 insertions(+), 16 deletions(-)
arch/x86/entry/entry_64.S +4 -4
@@ -1290,11 +1290,11 @@ ENTRY(nmi)
 	/* Unconditionally use kernel CR3 for do_nmi() */
 	/* %rax is saved above, so OK to clobber here */
 	movq	%cr3, %rax
+	/* If PCID enabled, NOFLUSH now and NOFLUSH on return */
+	orq	x86_cr3_pcid_noflush, %rax
 	pushq	%rax
 	/* mask off "user" bit of pgd address and 12 PCID bits: */
 	andq	$(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax
-	/* Add back kernel PCID and "no flush" bit */
-	orq	X86_CR3_PCID_KERN_VAR, %rax
 	movq	%rax, %cr3
 #endif
 	call	do_nmi
@@ -1534,11 +1534,11 @@ end_repeat_nmi:
 	/* Unconditionally use kernel CR3 for do_nmi() */
 	/* %rax is saved above, so OK to clobber here */
 	movq	%cr3, %rax
+	/* If PCID enabled, NOFLUSH now and NOFLUSH on return */
+	orq	x86_cr3_pcid_noflush, %rax
 	pushq	%rax
 	/* mask off "user" bit of pgd address and 12 PCID bits: */
 	andq	$(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax
-	/* Add back kernel PCID and "no flush" bit */
-	orq	X86_CR3_PCID_KERN_VAR, %rax
 	movq	%rax, %cr3
 #endif
 
arch/x86/include/asm/kaiser.h +5 -6
@@ -25,7 +25,7 @@
 .macro _SWITCH_TO_KERNEL_CR3 reg
 movq %cr3, \reg
 andq $(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), \reg
-orq  X86_CR3_PCID_KERN_VAR, \reg
+orq  x86_cr3_pcid_noflush, \reg
 movq \reg, %cr3
 .endm
 
@@ -37,11 +37,10 @@ movq \reg, %cr3
  * not enabled): so that the one register can update both memory and cr3.
  */
 movq %cr3, \reg
-andq $(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), \reg
-orq  PER_CPU_VAR(X86_CR3_PCID_USER_VAR), \reg
+orq  PER_CPU_VAR(x86_cr3_pcid_user), \reg
 js   9f
 /* FLUSH this time, reset to NOFLUSH for next time (if PCID enabled) */
-movb \regb, PER_CPU_VAR(X86_CR3_PCID_USER_VAR+7)
+movb \regb, PER_CPU_VAR(x86_cr3_pcid_user+7)
 9:
 movq \reg, %cr3
 .endm
@@ -94,8 +93,8 @@ movq PER_CPU_VAR(unsafe_stack_register_b
 */
 DECLARE_PER_CPU_USER_MAPPED(unsigned long, unsafe_stack_register_backup);
 
-extern unsigned long X86_CR3_PCID_KERN_VAR;
-DECLARE_PER_CPU(unsigned long, X86_CR3_PCID_USER_VAR);
+extern unsigned long x86_cr3_pcid_noflush;
+DECLARE_PER_CPU(unsigned long, x86_cr3_pcid_user);
 
 extern char __per_cpu_user_mapped_start[], __per_cpu_user_mapped_end[];
 
arch/x86/mm/kaiser.c +7 -6
@@ -29,8 +29,8 @@ DEFINE_PER_CPU_USER_MAPPED(unsigned long
  * This is also handy because systems that do not support PCIDs
  * just end up or'ing a 0 into their CR3, which does no harm.
  */
-__aligned(PAGE_SIZE) unsigned long X86_CR3_PCID_KERN_VAR;
-DEFINE_PER_CPU(unsigned long, X86_CR3_PCID_USER_VAR);
+unsigned long x86_cr3_pcid_noflush __read_mostly;
+DEFINE_PER_CPU(unsigned long, x86_cr3_pcid_user);
 
 /*
  * At runtime, the only things we map are some things for CPU
@@ -304,7 +304,8 @@ void __init kaiser_init(void)
 				  sizeof(gate_desc) * NR_VECTORS,
 				  __PAGE_KERNEL);
 
-	kaiser_add_user_map_early(&X86_CR3_PCID_KERN_VAR, PAGE_SIZE,
+	kaiser_add_user_map_early(&x86_cr3_pcid_noflush,
+				  sizeof(x86_cr3_pcid_noflush),
 				  __PAGE_KERNEL);
 }
 
@@ -384,8 +385,8 @@ void kaiser_setup_pcid(void)
 	 * These variables are used by the entry/exit
 	 * code to change PCID and pgd and TLB flushing.
 	 */
-	X86_CR3_PCID_KERN_VAR = kern_cr3;
-	this_cpu_write(X86_CR3_PCID_USER_VAR, user_cr3);
+	x86_cr3_pcid_noflush = kern_cr3;
+	this_cpu_write(x86_cr3_pcid_user, user_cr3);
 }
 
 /*
@@ -395,7 +396,7 @@ void kaiser_setup_pcid(void)
  */
 void kaiser_flush_tlb_on_return_to_user(void)
 {
-	this_cpu_write(X86_CR3_PCID_USER_VAR,
+	this_cpu_write(x86_cr3_pcid_user,
 			X86_CR3_PCID_USER_FLUSH | KAISER_SHADOW_PGD_OFFSET);
 }
 EXPORT_SYMBOL(kaiser_flush_tlb_on_return_to_user);
author maintainer
#22 lore raw

PATCH 22/37 kaiser: paranoid_entry pass cr3 need to paranoid_exit

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

Neel Natu points out that paranoid_entry() was wrong to assume that an entry that did not need swapgs would not need SWITCH_KERNEL_CR3:
paranoid_entry (used for debug breakpoint, int3, double fault or MCE; though I think it's only the MCE case that is cause for concern here) can break in at an awkward time, between cr3 switch and swapgs, but its handling always needs kernel gs and kernel cr3.

Easy to fix in itself, but paranoid_entry() also needs to convey to paranoid_exit() (and my reading of macro idtentry says paranoid_entry and paranoid_exit are always paired) how to restore the prior state. The swapgs state is already conveyed by %ebx (0 or 1), so extend that also to convey when SWITCH_USER_CR3 will be needed (2 or 3).

(Yes, I'd much prefer that 0 meant no swapgs, whereas it's the other way round: and a convention shared with error_entry() and error_exit(), which I don't want to touch. Perhaps I should have inverted the bit for switch cr3 too, but did not.)

paranoid_exit() would be straightforward, except for TRACE_IRQS: it did TRACE_IRQS_IRETQ when doing swapgs, but TRACE_IRQS_IRETQ_DEBUG when not: which is it supposed to use when SWITCH_USER_CR3 is split apart from that? As best as I can determine, commit 5963e317b1e9 ("ftrace/x86: Do not change stacks in DEBUG when calling lockdep") missed the swapgs case, and should have used TRACE_IRQS_IRETQ_DEBUG there too (the discrepancy has nothing to do with the liberal use of _NO_STACK and _UNSAFE_STACK hereabouts: TRACE_IRQS_OFF_DEBUG has just been used in all cases); discrepancy lovingly preserved across several paranoid_exit() cleanups, but I'm now removing it.

Neel further indicates that to use SWITCH_USER_CR3_NO_STACK there in paranoid_exit() is now not only unnecessary but unsafe: might corrupt syscall entry's unsafe_stack_register_backup of %rax. Just use
SWITCH_USER_CR3: and delete SWITCH_USER_CR3_NO_STACK altogether, before we make the mistake of using it again.

hughd adds: this commit fixes an issue in the Kaiser-without-PCIDs part of the series, and ought to be moved earlier, if you decided to make a release of Kaiser-without-PCIDs.

---
 arch/x86/entry/entry_64.S     |   46 ++++++++++++++++++++++++++++++++----------
 arch/x86/include/asm/kaiser.h |    8 -------
 2 files changed, 36 insertions(+), 18 deletions(-)
arch/x86/entry/entry_64.S +36 -10
@@ -1025,7 +1025,11 @@ idtentry machine_check					has_error_cod
 /*
  * Save all registers in pt_regs, and switch gs if needed.
  * Use slow, but surefire "are we in kernel?" check.
- * Return: ebx=0: need swapgs on exit, ebx=1: otherwise
+ *
+ * Return: ebx=0: needs swapgs but not SWITCH_USER_CR3 in paranoid_exit
+ *         ebx=1: needs neither swapgs nor SWITCH_USER_CR3 in paranoid_exit
+ *         ebx=2: needs both swapgs and SWITCH_USER_CR3 in paranoid_exit
+ *         ebx=3: needs SWITCH_USER_CR3 but not swapgs in paranoid_exit
  */
 ENTRY(paranoid_entry)
 	cld
@@ -1037,9 +1041,26 @@ ENTRY(paranoid_entry)
 	testl	%edx, %edx
 	js	1f				/* negative -> in kernel */
 	SWAPGS
-	SWITCH_KERNEL_CR3
 	xorl	%ebx, %ebx
-1:	ret
+1:
+#ifdef CONFIG_KAISER
+	/*
+	 * We might have come in between a swapgs and a SWITCH_KERNEL_CR3
+	 * on entry, or between a SWITCH_USER_CR3 and a swapgs on exit.
+	 * Do a conditional SWITCH_KERNEL_CR3: this could safely be done
+	 * unconditionally, but we need to find out whether the reverse
+	 * should be done on return (conveyed to paranoid_exit in %ebx).
+	 */
+	movq	%cr3, %rax
+	testl	$KAISER_SHADOW_PGD_OFFSET, %eax
+	jz	2f
+	orl	$2, %ebx
+	andq	$(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax
+	orq	x86_cr3_pcid_noflush, %rax
+	movq	%rax, %cr3
+2:
+#endif
+	ret
 END(paranoid_entry)
 
 /*
@@ -1052,20 +1073,25 @@ END(paranoid_entry)
  * be complicated.  Fortunately, we there's no good reason
  * to try to handle preemption here.
  *
- * On entry, ebx is "no swapgs" flag (1: don't need swapgs, 0: need it)
+ * On entry: ebx=0: needs swapgs but not SWITCH_USER_CR3
+ *           ebx=1: needs neither swapgs nor SWITCH_USER_CR3
+ *           ebx=2: needs both swapgs and SWITCH_USER_CR3
+ *           ebx=3: needs SWITCH_USER_CR3 but not swapgs
  */
 ENTRY(paranoid_exit)
 	DISABLE_INTERRUPTS(CLBR_NONE)
 	TRACE_IRQS_OFF_DEBUG
-	testl	%ebx, %ebx			/* swapgs needed? */
+	TRACE_IRQS_IRETQ_DEBUG
+#ifdef CONFIG_KAISER
+	testl	$2, %ebx			/* SWITCH_USER_CR3 needed? */
+	jz	paranoid_exit_no_switch
+	SWITCH_USER_CR3
+paranoid_exit_no_switch:
+#endif
+	testl	$1, %ebx			/* swapgs needed? */
 	jnz	paranoid_exit_no_swapgs
-	TRACE_IRQS_IRETQ
-	SWITCH_USER_CR3_NO_STACK
 	SWAPGS_UNSAFE_STACK
-	jmp	paranoid_exit_restore
 paranoid_exit_no_swapgs:
-	TRACE_IRQS_IRETQ_DEBUG
-paranoid_exit_restore:
 	RESTORE_EXTRA_REGS
 	RESTORE_C_REGS
 	REMOVE_PT_GPREGS_FROM_STACK 8
arch/x86/include/asm/kaiser.h +0 -8
@@ -63,20 +63,12 @@ _SWITCH_TO_KERNEL_CR3 %rax
 movq PER_CPU_VAR(unsafe_stack_register_backup), %rax
 .endm
 
-.macro SWITCH_USER_CR3_NO_STACK
-movq %rax, PER_CPU_VAR(unsafe_stack_register_backup)
-_SWITCH_TO_USER_CR3 %rax %al
-movq PER_CPU_VAR(unsafe_stack_register_backup), %rax
-.endm
-
 #else /* CONFIG_KAISER */
 
 .macro SWITCH_KERNEL_CR3 reg
 .endm
 .macro SWITCH_USER_CR3 reg regb
 .endm
-.macro SWITCH_USER_CR3_NO_STACK
-.endm
 .macro SWITCH_KERNEL_CR3_NO_STACK
 .endm
 
author maintainer
#23 lore raw

PATCH 23/37 kaiser: _pgd_alloc() without __GFP_REPEAT to avoid stalls

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

Synthetic filesystem mempressure testing has shown softlockups, with hour-long page allocation stalls, and pgd_alloc() trying for order:1 with __GFP_REPEAT in one of the backtraces each time.

That's _pgd_alloc() going for a Kaiser double-pgd, using the __GFP_REPEAT common to all page table allocations, but actually having no effect on order:0 (see should_alloc_oom() and should_continue_reclaim() in this tree, but beware that ports to another tree might behave differently).

Order:1 stack allocation has been working satisfactorily without __GFP_REPEAT forever, and page table allocation only asks __GFP_REPEAT for awkward occasions in a long-running process: it's not appropriate at fork or exec time, and seems to be doing much more harm than good:
getting those contiguous pages under very heavy mempressure can be hard (though even without it, Kaiser does generate more mempressure).

Mask out that __GFP_REPEAT inside _pgd_alloc(). Why not take it out of the PGALLOG_GFP altogether, as v4.7 commit a3a9a59d2067 ("x86: get rid of superfluous __GFP_REPEAT") did? Because I think that might make a difference to our page table memcg charging, which I'd prefer not to interfere with at this time.

hughd adds: __alloc_pages_slowpath() in the 4.4.89-stable tree handles __GFP_REPEAT a little differently than in prod kernel or 3.18.72-stable, so it may not always be exactly a no-op on order:0 pages, as said above; but I think still appropriate to omit it from Kaiser or non-Kaiser pgd.

---
 arch/x86/mm/pgtable.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
arch/x86/mm/pgtable.c +4 -2
@@ -6,7 +6,7 @@
 #include <asm/fixmap.h>
 #include <asm/mtrr.h>
 
-#define PGALLOC_GFP GFP_KERNEL | __GFP_NOTRACK | __GFP_REPEAT | __GFP_ZERO
+#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_REPEAT | __GFP_ZERO)
 
 #ifdef CONFIG_HIGHPTE
 #define PGALLOC_USER_GFP __GFP_HIGHMEM
@@ -354,7 +354,9 @@ static inline void _pgd_free(pgd_t *pgd)
 
 static inline pgd_t *_pgd_alloc(void)
 {
-	return (pgd_t *)__get_free_pages(PGALLOC_GFP, PGD_ALLOCATION_ORDER);
+	/* No __GFP_REPEAT: to avoid page allocation stalls in order-1 case */
+	return (pgd_t *)__get_free_pages(PGALLOC_GFP & ~__GFP_REPEAT,
+					 PGD_ALLOCATION_ORDER);
 }
 
 static inline void _pgd_free(pgd_t *pgd)
author maintainer
#24 lore raw

PATCH 24/37 kaiser: fix unlikely error in alloc_ldt_struct()

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

An error from kaiser_add_mapping() here is not at all likely, but Eric Biggers rightly points out that __free_ldt_struct() relies on new_ldt->size being initialized: move that up.

---
 arch/x86/kernel/ldt.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/ldt.c +1 -1
@@ -79,11 +79,11 @@ static struct ldt_struct *alloc_ldt_stru
 
 	ret = kaiser_add_mapping((unsigned long)new_ldt->entries, alloc_size,
 				 __PAGE_KERNEL);
+	new_ldt->size = size;
 	if (ret) {
 		__free_ldt_struct(new_ldt);
 		return NULL;
 	}
-	new_ldt->size = size;
 	return new_ldt;
 }
 
author maintainer
#25 lore raw

PATCH 25/37 kaiser: add "nokaiser" boot option, using ALTERNATIVE

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

Added "nokaiser" boot option: an early param like "noinvpcid". Most places now check int kaiser_enabled (#defined 0 when not CONFIG_KAISER) instead of #ifdef CONFIG_KAISER; but entry_64.S and entry_64_compat.S are using the ALTERNATIVE technique, which patches in the preferred instructions at runtime. That technique is tied to x86 cpu features, so X86_FEATURE_KAISER is fabricated.

Prior to "nokaiser", Kaiser #defined _PAGE_GLOBAL 0: revert that, but be careful with both _PAGE_GLOBAL and CR4.PGE: setting them when nokaiser like when !CONFIG_KAISER, but not setting either when kaiser - neither matters on its own, but it's hard to be sure that _PAGE_GLOBAL won't get set in some obscure corner, or something add PGE into CR4. By omitting _PAGE_GLOBAL from __supported_pte_mask when kaiser_enabled, all page table setup which uses pte_pfn() masks it out of the ptes.

It's slightly shameful that the same declaration versus definition of kaiser_enabled appears in not one, not two, but in three header files (asm/kaiser.h, asm/pgtable.h, asm/tlbflush.h). I felt safer that way, than with #including any of those in any of the others; and did not feel it worth an asm/kaiser_enabled.h - kernel/cpu/common.c includes them all, so we shall hear about it if they get out of synch.

Cleanups while in the area: removed the silly #ifdef CONFIG_KAISER from kaiser.c; removed the unused native_get_normal_pgd(); removed the spurious reg clutter from SWITCH_*_CR3 macro stubs; corrected some comments. But more interestingly, set CR4.PSE in secondary_startup_64:
the manual is clear that it does not matter whether it's 0 or 1 when 4-level-pts are enabled, but I was distracted to find cr4 different on BSP and auxiliaries - BSP alone was adding PSE, in probe_page_size_mask().

---
 Documentation/kernel-parameters.txt  |    2 +
 arch/x86/entry/entry_64.S            |   15 +++++++------
 arch/x86/include/asm/cpufeature.h    |    3 ++
 arch/x86/include/asm/kaiser.h        |   27 +++++++++++++++++-------
 arch/x86/include/asm/pgtable.h       |   20 ++++++++++++-----
 arch/x86/include/asm/pgtable_64.h    |   13 +++--------
 arch/x86/include/asm/pgtable_types.h |    4 ---
 arch/x86/include/asm/tlbflush.h      |   39 ++++++++++++++++++++++-------------
 arch/x86/kernel/cpu/common.c         |   28 ++++++++++++++++++++++++-
 arch/x86/kernel/espfix_64.c          |    3 +-
 arch/x86/kernel/head_64.S            |    4 +--
 arch/x86/mm/init.c                   |    2 -
 arch/x86/mm/init_64.c                |   10 ++++++++
 arch/x86/mm/kaiser.c                 |   26 +++++++++++++++++++----
 arch/x86/mm/pgtable.c                |    8 +------
 arch/x86/mm/tlb.c                    |    4 ---
 16 files changed, 143 insertions(+), 65 deletions(-)
Documentation/kernel-parameters.txt +2 -0
@@ -2523,6 +2523,8 @@ bytes respectively. Such letter suffixes
 
 	nojitter	[IA-64] Disables jitter checking for ITC timers.
 
+	nokaiser	[X86-64] Disable KAISER isolation of kernel from user.
+
 	no-kvmclock	[X86,KVM] Disable paravirtualized KVM clock driver
 
 	no-kvmapf	[X86,KVM] Disable paravirtualized asynchronous page
arch/x86/entry/entry_64.S +8 -7
@@ -1051,7 +1051,7 @@ ENTRY(paranoid_entry)
 	 * unconditionally, but we need to find out whether the reverse
 	 * should be done on return (conveyed to paranoid_exit in %ebx).
 	 */
-	movq	%cr3, %rax
+	ALTERNATIVE "jmp 2f", "movq %cr3, %rax", X86_FEATURE_KAISER
 	testl	$KAISER_SHADOW_PGD_OFFSET, %eax
 	jz	2f
 	orl	$2, %ebx
@@ -1083,6 +1083,7 @@ ENTRY(paranoid_exit)
 	TRACE_IRQS_OFF_DEBUG
 	TRACE_IRQS_IRETQ_DEBUG
 #ifdef CONFIG_KAISER
+	/* No ALTERNATIVE for X86_FEATURE_KAISER: paranoid_entry sets %ebx */
 	testl	$2, %ebx			/* SWITCH_USER_CR3 needed? */
 	jz	paranoid_exit_no_switch
 	SWITCH_USER_CR3
@@ -1315,13 +1316,14 @@ ENTRY(nmi)
 #ifdef CONFIG_KAISER
 	/* Unconditionally use kernel CR3 for do_nmi() */
 	/* %rax is saved above, so OK to clobber here */
-	movq	%cr3, %rax
+	ALTERNATIVE "jmp 2f", "movq %cr3, %rax", X86_FEATURE_KAISER
 	/* If PCID enabled, NOFLUSH now and NOFLUSH on return */
 	orq	x86_cr3_pcid_noflush, %rax
 	pushq	%rax
 	/* mask off "user" bit of pgd address and 12 PCID bits: */
 	andq	$(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax
 	movq	%rax, %cr3
+2:
 #endif
 	call	do_nmi
 
@@ -1331,8 +1333,7 @@ ENTRY(nmi)
 	 * kernel code that needs user CR3, but do we ever return
 	 * to "user mode" where we need the kernel CR3?
 	 */
-	popq	%rax
-	mov	%rax, %cr3
+	ALTERNATIVE "", "popq %rax; movq %rax, %cr3", X86_FEATURE_KAISER
 #endif
 
 	/*
@@ -1559,13 +1560,14 @@ end_repeat_nmi:
 #ifdef CONFIG_KAISER
 	/* Unconditionally use kernel CR3 for do_nmi() */
 	/* %rax is saved above, so OK to clobber here */
-	movq	%cr3, %rax
+	ALTERNATIVE "jmp 2f", "movq %cr3, %rax", X86_FEATURE_KAISER
 	/* If PCID enabled, NOFLUSH now and NOFLUSH on return */
 	orq	x86_cr3_pcid_noflush, %rax
 	pushq	%rax
 	/* mask off "user" bit of pgd address and 12 PCID bits: */
 	andq	$(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax
 	movq	%rax, %cr3
+2:
 #endif
 
 	/* paranoidentry do_nmi, 0; without TRACE_IRQS_OFF */
@@ -1577,8 +1579,7 @@ end_repeat_nmi:
 	 * kernel code that needs user CR3, like just just before
 	 * a sysret.
 	 */
-	popq	%rax
-	mov	%rax, %cr3
+	ALTERNATIVE "", "popq %rax; movq %rax, %cr3", X86_FEATURE_KAISER
 #endif
 
 	testl	%ebx, %ebx			/* swapgs needed? */
arch/x86/include/asm/cpufeature.h +3 -0
@@ -200,6 +200,9 @@
 #define X86_FEATURE_HWP_PKG_REQ ( 7*32+14) /* Intel HWP_PKG_REQ */
 #define X86_FEATURE_INTEL_PT	( 7*32+15) /* Intel Processor Trace */
 
+/* Because the ALTERNATIVE scheme is for members of the X86_FEATURE club... */
+#define X86_FEATURE_KAISER	( 7*32+31) /* CONFIG_KAISER w/o nokaiser */
+
 /* Virtualization flags: Linux defined, word 8 */
 #define X86_FEATURE_TPR_SHADOW  ( 8*32+ 0) /* Intel TPR Shadow */
 #define X86_FEATURE_VNMI        ( 8*32+ 1) /* Intel Virtual NMI */
arch/x86/include/asm/kaiser.h +20 -7
@@ -46,28 +46,33 @@ movq \reg, %cr3
 .endm
 
 .macro SWITCH_KERNEL_CR3
-pushq %rax
+ALTERNATIVE "jmp 8f", "pushq %rax", X86_FEATURE_KAISER
 _SWITCH_TO_KERNEL_CR3 %rax
 popq %rax
+8:
 .endm
 
 .macro SWITCH_USER_CR3
-pushq %rax
+ALTERNATIVE "jmp 8f", "pushq %rax", X86_FEATURE_KAISER
 _SWITCH_TO_USER_CR3 %rax %al
 popq %rax
+8:
 .endm
 
 .macro SWITCH_KERNEL_CR3_NO_STACK
-movq %rax, PER_CPU_VAR(unsafe_stack_register_backup)
+ALTERNATIVE "jmp 8f", \
+	__stringify(movq %rax, PER_CPU_VAR(unsafe_stack_register_backup)), \
+	X86_FEATURE_KAISER
 _SWITCH_TO_KERNEL_CR3 %rax
 movq PER_CPU_VAR(unsafe_stack_register_backup), %rax
+8:
 .endm
 
 #else /* CONFIG_KAISER */
 
-.macro SWITCH_KERNEL_CR3 reg
+.macro SWITCH_KERNEL_CR3
 .endm
-.macro SWITCH_USER_CR3 reg regb
+.macro SWITCH_USER_CR3
 .endm
 .macro SWITCH_KERNEL_CR3_NO_STACK
 .endm
@@ -90,6 +95,16 @@ DECLARE_PER_CPU(unsigned long, x86_cr3_p
 
 extern char __per_cpu_user_mapped_start[], __per_cpu_user_mapped_end[];
 
+extern int kaiser_enabled;
+#else
+#define kaiser_enabled	0
+#endif /* CONFIG_KAISER */
+
+/*
+ * Kaiser function prototypes are needed even when CONFIG_KAISER is not set,
+ * so as to build with tests on kaiser_enabled instead of #ifdefs.
+ */
+
 /**
  *  kaiser_add_mapping - map a virtual memory part to the shadow (user) mapping
  *  @addr: the start address of the range
@@ -119,8 +134,6 @@ extern void kaiser_remove_mapping(unsign
  */
 extern void kaiser_init(void);
 
-#endif /* CONFIG_KAISER */
-
 #endif /* __ASSEMBLY */
 
 #endif /* _ASM_X86_KAISER_H */
arch/x86/include/asm/pgtable.h +14 -6
@@ -18,6 +18,12 @@
 #ifndef __ASSEMBLY__
 #include <asm/x86_init.h>
 
+#ifdef CONFIG_KAISER
+extern int kaiser_enabled;
+#else
+#define kaiser_enabled 0
+#endif
+
 void ptdump_walk_pgd_level(struct seq_file *m, pgd_t *pgd);
 void ptdump_walk_pgd_level_checkwx(void);
 
@@ -660,7 +666,7 @@ static inline int pgd_bad(pgd_t pgd)
 	 * page table by accident; it will fault on the first
 	 * instruction it tries to run.  See native_set_pgd().
 	 */
-	if (IS_ENABLED(CONFIG_KAISER))
+	if (kaiser_enabled)
 		ignore_flags |= _PAGE_NX;
 
 	return (pgd_flags(pgd) & ~ignore_flags) != _KERNPG_TABLE;
@@ -865,12 +871,14 @@ static inline void pmdp_set_wrprotect(st
  */
 static inline void clone_pgd_range(pgd_t *dst, pgd_t *src, int count)
 {
-       memcpy(dst, src, count * sizeof(pgd_t));
+	memcpy(dst, src, count * sizeof(pgd_t));
 #ifdef CONFIG_KAISER
-	/* Clone the shadow pgd part as well */
-	memcpy(native_get_shadow_pgd(dst),
-	       native_get_shadow_pgd(src),
-	       count * sizeof(pgd_t));
+	if (kaiser_enabled) {
+		/* Clone the shadow pgd part as well */
+		memcpy(native_get_shadow_pgd(dst),
+			native_get_shadow_pgd(src),
+			count * sizeof(pgd_t));
+	}
 #endif
 }
 
arch/x86/include/asm/pgtable_64.h +4 -9
@@ -111,13 +111,12 @@ extern pgd_t kaiser_set_shadow_pgd(pgd_t
 
 static inline pgd_t *native_get_shadow_pgd(pgd_t *pgdp)
 {
+#ifdef CONFIG_DEBUG_VM
+	/* linux/mmdebug.h may not have been included at this point */
+	BUG_ON(!kaiser_enabled);
+#endif
 	return (pgd_t *)((unsigned long)pgdp | (unsigned long)PAGE_SIZE);
 }
-
-static inline pgd_t *native_get_normal_pgd(pgd_t *pgdp)
-{
-	return (pgd_t *)((unsigned long)pgdp & ~(unsigned long)PAGE_SIZE);
-}
 #else
 static inline pgd_t kaiser_set_shadow_pgd(pgd_t *pgdp, pgd_t pgd)
 {
@@ -128,10 +127,6 @@ static inline pgd_t *native_get_shadow_p
 	BUILD_BUG_ON(1);
 	return NULL;
 }
-static inline pgd_t *native_get_normal_pgd(pgd_t *pgdp)
-{
-	return pgdp;
-}
 #endif /* CONFIG_KAISER */
 
 static inline void native_set_pgd(pgd_t *pgdp, pgd_t pgd)
arch/x86/include/asm/pgtable_types.h +0 -4
@@ -39,11 +39,7 @@
 #define _PAGE_ACCESSED	(_AT(pteval_t, 1) << _PAGE_BIT_ACCESSED)
 #define _PAGE_DIRTY	(_AT(pteval_t, 1) << _PAGE_BIT_DIRTY)
 #define _PAGE_PSE	(_AT(pteval_t, 1) << _PAGE_BIT_PSE)
-#ifdef CONFIG_KAISER
-#define _PAGE_GLOBAL	(_AT(pteval_t, 0))
-#else
 #define _PAGE_GLOBAL	(_AT(pteval_t, 1) << _PAGE_BIT_GLOBAL)
-#endif
 #define _PAGE_SOFTW1	(_AT(pteval_t, 1) << _PAGE_BIT_SOFTW1)
 #define _PAGE_SOFTW2	(_AT(pteval_t, 1) << _PAGE_BIT_SOFTW2)
 #define _PAGE_PAT	(_AT(pteval_t, 1) << _PAGE_BIT_PAT)
arch/x86/include/asm/tlbflush.h +25 -14
@@ -136,9 +136,11 @@ static inline void cr4_set_bits_and_upda
  * to avoid the need for asm/kaiser.h in unexpected places.
  */
 #ifdef CONFIG_KAISER
+extern int kaiser_enabled;
 extern void kaiser_setup_pcid(void);
 extern void kaiser_flush_tlb_on_return_to_user(void);
 #else
+#define kaiser_enabled 0
 static inline void kaiser_setup_pcid(void)
 {
 }
@@ -163,7 +165,7 @@ static inline void __native_flush_tlb(vo
 	 * back:
 	 */
 	preempt_disable();
-	if (this_cpu_has(X86_FEATURE_PCID))
+	if (kaiser_enabled && this_cpu_has(X86_FEATURE_PCID))
 		kaiser_flush_tlb_on_return_to_user();
 	native_write_cr3(native_read_cr3());
 	preempt_enable();
@@ -174,20 +176,30 @@ static inline void __native_flush_tlb_gl
 	unsigned long cr4;
 
 	cr4 = this_cpu_read(cpu_tlbstate.cr4);
-	/* clear PGE */
-	native_write_cr4(cr4 & ~X86_CR4_PGE);
-	/* write old PGE again and flush TLBs */
-	native_write_cr4(cr4);
+	if (cr4 & X86_CR4_PGE) {
+		/* clear PGE and flush TLB of all entries */
+		native_write_cr4(cr4 & ~X86_CR4_PGE);
+		/* restore PGE as it was before */
+		native_write_cr4(cr4);
+	} else {
+		/*
+		 * x86_64 microcode update comes this way when CR4.PGE is not
+		 * enabled, and it's safer for all callers to allow this case.
+		 */
+		native_write_cr3(native_read_cr3());
+	}
 }
 
 static inline void __native_flush_tlb_global(void)
 {
-#ifdef CONFIG_KAISER
-	/* Globals are not used at all */
-	__native_flush_tlb();
-#else
 	unsigned long flags;
 
+	if (kaiser_enabled) {
+		/* Globals are not used at all */
+		__native_flush_tlb();
+		return;
+	}
+
 	if (this_cpu_has(X86_FEATURE_INVPCID)) {
 		/*
 		 * Using INVPCID is considerably faster than a pair of writes
@@ -207,7 +219,6 @@ static inline void __native_flush_tlb_gl
 	raw_local_irq_save(flags);
 	__native_flush_tlb_global_irq_disabled();
 	raw_local_irq_restore(flags);
-#endif
 }
 
 static inline void __native_flush_tlb_single(unsigned long addr)
@@ -222,7 +233,7 @@ static inline void __native_flush_tlb_si
 	 */
 
 	if (!this_cpu_has(X86_FEATURE_INVPCID_SINGLE)) {
-		if (this_cpu_has(X86_FEATURE_PCID))
+		if (kaiser_enabled && this_cpu_has(X86_FEATURE_PCID))
 			kaiser_flush_tlb_on_return_to_user();
 		asm volatile("invlpg (%0)" ::"r" (addr) : "memory");
 		return;
@@ -237,9 +248,9 @@ static inline void __native_flush_tlb_si
 	 * Make sure to do only a single invpcid when KAISER is
 	 * disabled and we have only a single ASID.
 	 */
-	if (X86_CR3_PCID_ASID_KERN != X86_CR3_PCID_ASID_USER)
-		invpcid_flush_one(X86_CR3_PCID_ASID_KERN, addr);
-	invpcid_flush_one(X86_CR3_PCID_ASID_USER, addr);
+	if (kaiser_enabled)
+		invpcid_flush_one(X86_CR3_PCID_ASID_USER, addr);
+	invpcid_flush_one(X86_CR3_PCID_ASID_KERN, addr);
 }
 
 static inline void __flush_tlb_all(void)
arch/x86/kernel/cpu/common.c +27 -1
@@ -178,6 +178,20 @@ static int __init x86_pcid_setup(char *s
 	return 1;
 }
 __setup("nopcid", x86_pcid_setup);
+
+static int __init x86_nokaiser_setup(char *s)
+{
+	/* nokaiser doesn't accept parameters */
+	if (s)
+		return -EINVAL;
+#ifdef CONFIG_KAISER
+	kaiser_enabled = 0;
+	setup_clear_cpu_cap(X86_FEATURE_KAISER);
+	pr_info("nokaiser: KAISER feature disabled\n");
+#endif
+	return 0;
+}
+early_param("nokaiser", x86_nokaiser_setup);
 #endif
 
 static int __init x86_noinvpcid_setup(char *s)
@@ -324,7 +338,7 @@ static __always_inline void setup_smap(s
 static void setup_pcid(struct cpuinfo_x86 *c)
 {
 	if (cpu_has(c, X86_FEATURE_PCID)) {
-		if (cpu_has(c, X86_FEATURE_PGE)) {
+		if (cpu_has(c, X86_FEATURE_PGE) || kaiser_enabled) {
 			cr4_set_bits(X86_CR4_PCIDE);
 			/*
 			 * INVPCID has two "groups" of types:
@@ -747,6 +761,10 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
 		c->x86_power = cpuid_edx(0x80000007);
 
 	init_scattered_cpuid_features(c);
+#ifdef CONFIG_KAISER
+	if (kaiser_enabled)
+		set_cpu_cap(c, X86_FEATURE_KAISER);
+#endif
 }
 
 static void identify_cpu_without_cpuid(struct cpuinfo_x86 *c)
@@ -1406,6 +1424,14 @@ void cpu_init(void)
 	 * try to read it.
 	 */
 	cr4_init_shadow();
+	if (!kaiser_enabled) {
+		/*
+		 * secondary_startup_64() deferred setting PGE in cr4:
+		 * probe_page_size_mask() sets it on the boot cpu,
+		 * but it needs to be set on each secondary cpu.
+		 */
+		cr4_set_bits(X86_CR4_PGE);
+	}
 
 	/*
 	 * Load microcode on this cpu if a valid microcode is available.
arch/x86/kernel/espfix_64.c +2 -1
@@ -132,9 +132,10 @@ void __init init_espfix_bsp(void)
 	 * area to ensure it is mapped into the shadow user page
 	 * tables.
 	 */
-	if (IS_ENABLED(CONFIG_KAISER))
+	if (kaiser_enabled) {
 		set_pgd(native_get_shadow_pgd(pgd_p),
 			__pgd(_KERNPG_TABLE | __pa((pud_t *)espfix_pud_page)));
+	}
 
 	/* Randomize the locations */
 	init_espfix_random();
arch/x86/kernel/head_64.S +2 -2
@@ -183,8 +183,8 @@ ENTRY(secondary_startup_64)
 	movq	$(init_level4_pgt - __START_KERNEL_map), %rax
 1:
 
-	/* Enable PAE mode and PGE */
-	movl	$(X86_CR4_PAE | X86_CR4_PGE), %ecx
+	/* Enable PAE and PSE, but defer PGE until kaiser_enabled is decided */
+	movl	$(X86_CR4_PAE | X86_CR4_PSE), %ecx
 	movq	%rcx, %cr4
 
 	/* Setup early boot stage 4 level pagetables. */
arch/x86/mm/init.c +1 -1
@@ -165,7 +165,7 @@ static void __init probe_page_size_mask(
 		cr4_set_bits_and_update_boot(X86_CR4_PSE);
 
 	/* Enable PGE if available */
-	if (cpu_has_pge) {
+	if (cpu_has_pge && !kaiser_enabled) {
 		cr4_set_bits_and_update_boot(X86_CR4_PGE);
 		__supported_pte_mask |= _PAGE_GLOBAL;
 	} else
arch/x86/mm/init_64.c +10 -0
@@ -395,6 +395,16 @@ void __init cleanup_highmap(void)
 			continue;
 		if (vaddr < (unsigned long) _text || vaddr > end)
 			set_pmd(pmd, __pmd(0));
+		else if (kaiser_enabled) {
+			/*
+			 * level2_kernel_pgt is initialized with _PAGE_GLOBAL:
+			 * clear that now.  This is not important, so long as
+			 * CR4.PGE remains clear, but it removes an anomaly.
+			 * Physical mapping setup below avoids _PAGE_GLOBAL
+			 * by use of massage_pgprot() inside pfn_pte() etc.
+			 */
+			set_pmd(pmd, pmd_clear_flags(*pmd, _PAGE_GLOBAL));
+		}
 	}
 }
 
arch/x86/mm/kaiser.c +22 -4
@@ -17,7 +17,9 @@
 #include <asm/pgalloc.h>
 #include <asm/desc.h>
 
-#ifdef CONFIG_KAISER
+int kaiser_enabled __read_mostly = 1;
+EXPORT_SYMBOL(kaiser_enabled);	/* for inlined TLB flush functions */
+
 __visible
 DEFINE_PER_CPU_USER_MAPPED(unsigned long, unsafe_stack_register_backup);
 
@@ -168,8 +170,8 @@ static pte_t *kaiser_pagetable_walk(unsi
 	return pte_offset_kernel(pmd, address);
 }
 
-int kaiser_add_user_map(const void *__start_addr, unsigned long size,
-			unsigned long flags)
+static int kaiser_add_user_map(const void *__start_addr, unsigned long size,
+			       unsigned long flags)
 {
 	int ret = 0;
 	pte_t *pte;
@@ -178,6 +180,15 @@ int kaiser_add_user_map(const void *__st
 	unsigned long end_addr = PAGE_ALIGN(start_addr + size);
 	unsigned long target_address;
 
+	/*
+	 * It is convenient for callers to pass in __PAGE_KERNEL etc,
+	 * and there is no actual harm from setting _PAGE_GLOBAL, so
+	 * long as CR4.PGE is not set.  But it is nonetheless troubling
+	 * to see Kaiser itself setting _PAGE_GLOBAL (now that "nokaiser"
+	 * requires that not to be #defined to 0): so mask it off here.
+	 */
+	flags &= ~_PAGE_GLOBAL;
+
 	for (; address < end_addr; address += PAGE_SIZE) {
 		target_address = get_pa_from_mapping(address);
 		if (target_address == -1) {
@@ -264,6 +275,8 @@ void __init kaiser_init(void)
 {
 	int cpu;
 
+	if (!kaiser_enabled)
+		return;
 	kaiser_init_all_pgds();
 
 	for_each_possible_cpu(cpu) {
@@ -312,6 +325,8 @@ void __init kaiser_init(void)
 /* Add a mapping to the shadow mapping, and synchronize the mappings */
 int kaiser_add_mapping(unsigned long addr, unsigned long size, unsigned long flags)
 {
+	if (!kaiser_enabled)
+		return 0;
 	return kaiser_add_user_map((const void *)addr, size, flags);
 }
 
@@ -323,6 +338,8 @@ void kaiser_remove_mapping(unsigned long
 	unsigned long addr, next;
 	pgd_t *pgd;
 
+	if (!kaiser_enabled)
+		return;
 	pgd = native_get_shadow_pgd(pgd_offset_k(start));
 	for (addr = start; addr < end; pgd++, addr = next) {
 		next = pgd_addr_end(addr, end);
@@ -344,6 +361,8 @@ static inline bool is_userspace_pgd(pgd_
 
 pgd_t kaiser_set_shadow_pgd(pgd_t *pgdp, pgd_t pgd)
 {
+	if (!kaiser_enabled)
+		return pgd;
 	/*
 	 * Do we need to also populate the shadow pgd?  Check _PAGE_USER to
 	 * skip cases like kexec and EFI which make temporary low mappings.
@@ -400,4 +419,3 @@ void kaiser_flush_tlb_on_return_to_user(
 			X86_CR3_PCID_USER_FLUSH | KAISER_SHADOW_PGD_OFFSET);
 }
 EXPORT_SYMBOL(kaiser_flush_tlb_on_return_to_user);
-#endif /* CONFIG_KAISER */
arch/x86/mm/pgtable.c +2 -6
@@ -341,16 +341,12 @@ static inline void _pgd_free(pgd_t *pgd)
 }
 #else
 
-#ifdef CONFIG_KAISER
 /*
- * Instead of one pmd, we aquire two pmds.  Being order-1, it is
+ * Instead of one pgd, Kaiser acquires two pgds.  Being order-1, it is
  * both 8k in size and 8k-aligned.  That lets us just flip bit 12
  * in a pointer to swap between the two 4k halves.
  */
-#define PGD_ALLOCATION_ORDER 1
-#else
-#define PGD_ALLOCATION_ORDER 0
-#endif
+#define PGD_ALLOCATION_ORDER	kaiser_enabled
 
 static inline pgd_t *_pgd_alloc(void)
 {
arch/x86/mm/tlb.c +1 -3
@@ -39,8 +39,7 @@ static void load_new_mm_cr3(pgd_t *pgdir
 {
 	unsigned long new_mm_cr3 = __pa(pgdir);
 
-#ifdef CONFIG_KAISER
-	if (this_cpu_has(X86_FEATURE_PCID)) {
+	if (kaiser_enabled && this_cpu_has(X86_FEATURE_PCID)) {
 		/*
 		 * We reuse the same PCID for different tasks, so we must
 		 * flush all the entries for the PCID out when we change tasks.
@@ -57,7 +56,6 @@ static void load_new_mm_cr3(pgd_t *pgdir
 		new_mm_cr3 |= X86_CR3_PCID_KERN_FLUSH;
 		kaiser_flush_tlb_on_return_to_user();
 	}
-#endif /* CONFIG_KAISER */
 
 	/*
 	 * Caution: many callers of this function expect
author maintainer
#26 lore raw

PATCH 26/37 x86/kaiser: Rename and simplify X86_FEATURE_KAISER handling

In reply to Greg Kroah-Hartman

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

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

From: Borislav Petkov <[email protected]>

Concentrate it in arch/x86/mm/kaiser.c and use the upstream string "nopti".

---
 Documentation/kernel-parameters.txt |    2 +-
 arch/x86/kernel/cpu/common.c        |   18 ------------------
 arch/x86/mm/kaiser.c                |   20 +++++++++++++++++++-
 3 files changed, 20 insertions(+), 20 deletions(-)
Documentation/kernel-parameters.txt +1 -1
@@ -2523,7 +2523,7 @@ bytes respectively. Such letter suffixes
 
 	nojitter	[IA-64] Disables jitter checking for ITC timers.
 
-	nokaiser	[X86-64] Disable KAISER isolation of kernel from user.
+	nopti		[X86-64] Disable KAISER isolation of kernel from user.
 
 	no-kvmclock	[X86,KVM] Disable paravirtualized KVM clock driver
 
arch/x86/kernel/cpu/common.c +0 -18
@@ -178,20 +178,6 @@ static int __init x86_pcid_setup(char *s
 	return 1;
 }
 __setup("nopcid", x86_pcid_setup);
-
-static int __init x86_nokaiser_setup(char *s)
-{
-	/* nokaiser doesn't accept parameters */
-	if (s)
-		return -EINVAL;
-#ifdef CONFIG_KAISER
-	kaiser_enabled = 0;
-	setup_clear_cpu_cap(X86_FEATURE_KAISER);
-	pr_info("nokaiser: KAISER feature disabled\n");
-#endif
-	return 0;
-}
-early_param("nokaiser", x86_nokaiser_setup);
 #endif
 
 static int __init x86_noinvpcid_setup(char *s)
@@ -761,10 +747,6 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
 		c->x86_power = cpuid_edx(0x80000007);
 
 	init_scattered_cpuid_features(c);
-#ifdef CONFIG_KAISER
-	if (kaiser_enabled)
-		set_cpu_cap(c, X86_FEATURE_KAISER);
-#endif
 }
 
 static void identify_cpu_without_cpuid(struct cpuinfo_x86 *c)
arch/x86/mm/kaiser.c +19 -1
@@ -275,8 +275,13 @@ void __init kaiser_init(void)
 {
 	int cpu;
 
-	if (!kaiser_enabled)
+	if (!kaiser_enabled) {
+		setup_clear_cpu_cap(X86_FEATURE_KAISER);
 		return;
+	}
+
+	setup_force_cpu_cap(X86_FEATURE_KAISER);
+
 	kaiser_init_all_pgds();
 
 	for_each_possible_cpu(cpu) {
@@ -419,3 +424,16 @@ void kaiser_flush_tlb_on_return_to_user(
 			X86_CR3_PCID_USER_FLUSH | KAISER_SHADOW_PGD_OFFSET);
 }
 EXPORT_SYMBOL(kaiser_flush_tlb_on_return_to_user);
+
+static int __init x86_nokaiser_setup(char *s)
+{
+	/* nopti doesn't accept parameters */
+	if (s)
+		return -EINVAL;
+
+	kaiser_enabled = 0;
+	pr_info("Kernel/User page tables isolation: disabled\n");
+
+	return 0;
+}
+early_param("nopti", x86_nokaiser_setup);
author maintainer
#27 lore raw

PATCH 27/37 x86/kaiser: Check boottime cmdline params

In reply to Greg Kroah-Hartman

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

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

From: Borislav Petkov <[email protected]>

AMD (and possibly other vendors) are not affected by the leak KAISER is protecting against.

Keep the "nopti" for traditional reasons and add pti=<on|off|auto> like upstream.

---
 Documentation/kernel-parameters.txt |    6 +++
 arch/x86/mm/kaiser.c                |   59 +++++++++++++++++++++++++-----------
 2 files changed, 47 insertions(+), 18 deletions(-)
Documentation/kernel-parameters.txt +6 -0
@@ -3056,6 +3056,12 @@ bytes respectively. Such letter suffixes
 	pt.		[PARIDE]
 			See Documentation/blockdev/paride.txt.
 
+	pti=		[X86_64]
+			Control KAISER user/kernel address space isolation:
+			on - enable
+			off - disable
+			auto - default setting
+
 	pty.legacy_count=
 			[KNL] Number of legacy pty's. Overwrites compiled-in
 			default number.
arch/x86/mm/kaiser.c +41 -18

81 lines not on this page · raw message

author maintainer
#28 lore raw

PATCH 28/37 kaiser: use ALTERNATIVE instead of x86_cr3_pcid_noflush

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

Now that we're playing the ALTERNATIVE game, use that more efficient
method: instead of user-mapping an extra page, and reading an extra cacheline each time for x86_cr3_pcid_noflush.

Neel has found that __stringify(bts $X86_CR3_PCID_NOFLUSH_BIT, %rax) is a working substitute for the "bts $63, %rax" in these ALTERNATIVEs; but the one line with $63 in looks clearer, so let's stick with that.

Worried about what happens with an ALTERNATIVE between the jump and jump label in another ALTERNATIVE? I was, but have checked the combinations in SWITCH_KERNEL_CR3_NO_STACK at entry_SYSCALL_64, and it does a good job.

---
 arch/x86/entry/entry_64.S     |    7 ++++---
 arch/x86/include/asm/kaiser.h |    6 +++---
 arch/x86/mm/kaiser.c          |   11 +----------
 3 files changed, 8 insertions(+), 16 deletions(-)
arch/x86/entry/entry_64.S +4 -3
@@ -1056,7 +1056,8 @@ ENTRY(paranoid_entry)
 	jz	2f
 	orl	$2, %ebx
 	andq	$(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax
-	orq	x86_cr3_pcid_noflush, %rax
+	/* If PCID enabled, set X86_CR3_PCID_NOFLUSH_BIT */
+	ALTERNATIVE "", "bts $63, %rax", X86_FEATURE_PCID
 	movq	%rax, %cr3
 2:
 #endif
@@ -1318,7 +1319,7 @@ ENTRY(nmi)
 	/* %rax is saved above, so OK to clobber here */
 	ALTERNATIVE "jmp 2f", "movq %cr3, %rax", X86_FEATURE_KAISER
 	/* If PCID enabled, NOFLUSH now and NOFLUSH on return */
-	orq	x86_cr3_pcid_noflush, %rax
+	ALTERNATIVE "", "bts $63, %rax", X86_FEATURE_PCID
 	pushq	%rax
 	/* mask off "user" bit of pgd address and 12 PCID bits: */
 	andq	$(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax
@@ -1562,7 +1563,7 @@ end_repeat_nmi:
 	/* %rax is saved above, so OK to clobber here */
 	ALTERNATIVE "jmp 2f", "movq %cr3, %rax", X86_FEATURE_KAISER
 	/* If PCID enabled, NOFLUSH now and NOFLUSH on return */
-	orq	x86_cr3_pcid_noflush, %rax
+	ALTERNATIVE "", "bts $63, %rax", X86_FEATURE_PCID
 	pushq	%rax
 	/* mask off "user" bit of pgd address and 12 PCID bits: */
 	andq	$(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax
arch/x86/include/asm/kaiser.h +3 -3
@@ -25,7 +25,8 @@
 .macro _SWITCH_TO_KERNEL_CR3 reg
 movq %cr3, \reg
 andq $(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), \reg
-orq  x86_cr3_pcid_noflush, \reg
+/* If PCID enabled, set X86_CR3_PCID_NOFLUSH_BIT */
+ALTERNATIVE "", "bts $63, \reg", X86_FEATURE_PCID
 movq \reg, %cr3
 .endm
 
@@ -39,7 +40,7 @@ movq \reg, %cr3
 movq %cr3, \reg
 orq  PER_CPU_VAR(x86_cr3_pcid_user), \reg
 js   9f
-/* FLUSH this time, reset to NOFLUSH for next time (if PCID enabled) */
+/* If PCID enabled, FLUSH this time, reset to NOFLUSH for next time */
 movb \regb, PER_CPU_VAR(x86_cr3_pcid_user+7)
 9:
 movq \reg, %cr3
@@ -90,7 +91,6 @@ movq PER_CPU_VAR(unsafe_stack_register_b
 */
 DECLARE_PER_CPU_USER_MAPPED(unsigned long, unsafe_stack_register_backup);
 
-extern unsigned long x86_cr3_pcid_noflush;
 DECLARE_PER_CPU(unsigned long, x86_cr3_pcid_user);
 
 extern char __per_cpu_user_mapped_start[], __per_cpu_user_mapped_end[];
arch/x86/mm/kaiser.c +1 -10
@@ -32,7 +32,6 @@ DEFINE_PER_CPU_USER_MAPPED(unsigned long
  * This is also handy because systems that do not support PCIDs
  * just end up or'ing a 0 into their CR3, which does no harm.
  */
-unsigned long x86_cr3_pcid_noflush __read_mostly;
 DEFINE_PER_CPU(unsigned long, x86_cr3_pcid_user);
 
 /*
@@ -357,10 +356,6 @@ void __init kaiser_init(void)
 	kaiser_add_user_map_early(&debug_idt_table,
 				  sizeof(gate_desc) * NR_VECTORS,
 				  __PAGE_KERNEL);
-
-	kaiser_add_user_map_early(&x86_cr3_pcid_noflush,
-				  sizeof(x86_cr3_pcid_noflush),
-				  __PAGE_KERNEL);
 }
 
 /* Add a mapping to the shadow mapping, and synchronize the mappings */
@@ -434,18 +429,14 @@ pgd_t kaiser_set_shadow_pgd(pgd_t *pgdp,
 
 void kaiser_setup_pcid(void)
 {
-	unsigned long kern_cr3 = 0;
 	unsigned long user_cr3 = KAISER_SHADOW_PGD_OFFSET;
 
-	if (this_cpu_has(X86_FEATURE_PCID)) {
-		kern_cr3 |= X86_CR3_PCID_KERN_NOFLUSH;
+	if (this_cpu_has(X86_FEATURE_PCID))
 		user_cr3 |= X86_CR3_PCID_USER_NOFLUSH;
-	}
 	/*
 	 * These variables are used by the entry/exit
 	 * code to change PCID and pgd and TLB flushing.
 	 */
-	x86_cr3_pcid_noflush = kern_cr3;
 	this_cpu_write(x86_cr3_pcid_user, user_cr3);
 }
 
author maintainer
#29 lore raw

PATCH 29/37 kaiser: drop is_atomic arg to kaiser_pagetable_walk()

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

I have not observed a might_sleep() warning from setup_fixmap_gdt()'s use of kaiser_add_mapping() in our tree (why not?), but like upstream we have not provided a way for that to pass is_atomic true down to kaiser_pagetable_walk(), and at startup it's far from a likely source of trouble: so just delete the walk's is_atomic arg and might_sleep().

---
 arch/x86/mm/kaiser.c |   10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)
arch/x86/mm/kaiser.c +2 -8
@@ -108,19 +108,13 @@ static inline unsigned long get_pa_from_
  *
  * Returns a pointer to a PTE on success, or NULL on failure.
  */
-static pte_t *kaiser_pagetable_walk(unsigned long address, bool is_atomic)
+static pte_t *kaiser_pagetable_walk(unsigned long address)
 {
 	pmd_t *pmd;
 	pud_t *pud;
 	pgd_t *pgd = native_get_shadow_pgd(pgd_offset_k(address));
 	gfp_t gfp = (GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO);
 
-	if (is_atomic) {
-		gfp &= ~GFP_KERNEL;
-		gfp |= __GFP_HIGH | __GFP_ATOMIC;
-	} else
-		might_sleep();
-
 	if (pgd_none(*pgd)) {
 		WARN_ONCE(1, "All shadow pgds should have been populated");
 		return NULL;
@@ -195,7 +189,7 @@ static int kaiser_add_user_map(const voi
 			ret = -EIO;
 			break;
 		}
-		pte = kaiser_pagetable_walk(address, false);
+		pte = kaiser_pagetable_walk(address);
 		if (!pte) {
 			ret = -ENOMEM;
 			break;
author maintainer
#30 lore raw

PATCH 30/37 kaiser: asm/tlbflush.h handle noPGE at lower level

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

I found asm/tlbflush.h too twisty, and think it safer not to avoid __native_flush_tlb_global_irq_disabled() in the kaiser_enabled case, but instead let it handle kaiser_enabled along with cr3: it can just use __native_flush_tlb() for that, no harm in re-disabling preemption.

(This is not the same change as Kirill and Dave have suggested for upstream, flipping PGE in cr4: that's neat, but needs a cpu_has_pge check; cr3 is enough for kaiser, and thought to be cheaper than cr4.)

Also delete the X86_FEATURE_INVPCID invpcid_flush_all_nonglobals() preference from __native_flush_tlb(): unlike the invpcid_flush_all() preference in __native_flush_tlb_global(), it's not seen in upstream 4.14, and was recently reported to be surprisingly slow.

---
 arch/x86/include/asm/tlbflush.h |   27 +++------------------------
 1 file changed, 3 insertions(+), 24 deletions(-)
arch/x86/include/asm/tlbflush.h +3 -24
@@ -151,14 +151,6 @@ static inline void kaiser_flush_tlb_on_r
 
 static inline void __native_flush_tlb(void)
 {
-	if (this_cpu_has(X86_FEATURE_INVPCID)) {
-		/*
-		 * Note, this works with CR4.PCIDE=0 or 1.
-		 */
-		invpcid_flush_all_nonglobals();
-		return;
-	}
-
 	/*
 	 * If current->mm == NULL then we borrow a mm which may change during a
 	 * task switch and therefore we must not be preempted while we write CR3
@@ -182,11 +174,8 @@ static inline void __native_flush_tlb_gl
 		/* restore PGE as it was before */
 		native_write_cr4(cr4);
 	} else {
-		/*
-		 * x86_64 microcode update comes this way when CR4.PGE is not
-		 * enabled, and it's safer for all callers to allow this case.
-		 */
-		native_write_cr3(native_read_cr3());
+		/* do it with cr3, letting kaiser flush user PCID */
+		__native_flush_tlb();
 	}
 }
 
@@ -194,12 +183,6 @@ static inline void __native_flush_tlb_gl
 {
 	unsigned long flags;
 
-	if (kaiser_enabled) {
-		/* Globals are not used at all */
-		__native_flush_tlb();
-		return;
-	}
-
 	if (this_cpu_has(X86_FEATURE_INVPCID)) {
 		/*
 		 * Using INVPCID is considerably faster than a pair of writes
@@ -255,11 +238,7 @@ static inline void __native_flush_tlb_si
 
 static inline void __flush_tlb_all(void)
 {
-	if (cpu_has_pge)
-		__flush_tlb_global();
-	else
-		__flush_tlb();
-
+	__flush_tlb_global();
 	/*
 	 * Note: if we somehow had PCID but not PGE, then this wouldn't work --
 	 * we'd end up flushing kernel translations for the current ASID but
author maintainer
#31 lore raw

PATCH 31/37 kaiser: kaiser_flush_tlb_on_return_to_user() check PCID

In reply to Greg Kroah-Hartman

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

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

From: Hugh Dickins <[email protected]>

Let kaiser_flush_tlb_on_return_to_user() do the X86_FEATURE_PCID check, instead of each caller doing it inline first: nobody needs to optimize for the noPCID case, it's clearer this way, and better suits later changes. Replace those no-op X86_CR3_PCID_KERN_FLUSH lines by a BUILD_BUG_ON() in load_new_mm_cr3(), in case something changes.

---
 arch/x86/include/asm/tlbflush.h |    4 ++--
 arch/x86/mm/kaiser.c            |    6 +++---
 arch/x86/mm/tlb.c               |    8 ++++----
 3 files changed, 9 insertions(+), 9 deletions(-)
arch/x86/include/asm/tlbflush.h +2 -2
@@ -157,7 +157,7 @@ static inline void __native_flush_tlb(vo
 	 * back:
 	 */
 	preempt_disable();
-	if (kaiser_enabled && this_cpu_has(X86_FEATURE_PCID))
+	if (kaiser_enabled)
 		kaiser_flush_tlb_on_return_to_user();
 	native_write_cr3(native_read_cr3());
 	preempt_enable();
@@ -216,7 +216,7 @@ static inline void __native_flush_tlb_si
 	 */
 
 	if (!this_cpu_has(X86_FEATURE_INVPCID_SINGLE)) {
-		if (kaiser_enabled && this_cpu_has(X86_FEATURE_PCID))
+		if (kaiser_enabled)
 			kaiser_flush_tlb_on_return_to_user();
 		asm volatile("invlpg (%0)" ::"r" (addr) : "memory");
 		return;
arch/x86/mm/kaiser.c +3 -3
@@ -436,12 +436,12 @@ void kaiser_setup_pcid(void)
 
 /*
  * Make a note that this cpu will need to flush USER tlb on return to user.
- * Caller checks whether this_cpu_has(X86_FEATURE_PCID) before calling:
- * if cpu does not, then the NOFLUSH bit will never have been set.
+ * If cpu does not have PCID, then the NOFLUSH bit will never have been set.
  */
 void kaiser_flush_tlb_on_return_to_user(void)
 {
-	this_cpu_write(x86_cr3_pcid_user,
+	if (this_cpu_has(X86_FEATURE_PCID))
+		this_cpu_write(x86_cr3_pcid_user,
 			X86_CR3_PCID_USER_FLUSH | KAISER_SHADOW_PGD_OFFSET);
 }
 EXPORT_SYMBOL(kaiser_flush_tlb_on_return_to_user);
arch/x86/mm/tlb.c +4 -4
@@ -39,7 +39,7 @@ static void load_new_mm_cr3(pgd_t *pgdir
 {
 	unsigned long new_mm_cr3 = __pa(pgdir);
 
-	if (kaiser_enabled && this_cpu_has(X86_FEATURE_PCID)) {
+	if (kaiser_enabled) {
 		/*
 		 * We reuse the same PCID for different tasks, so we must
 		 * flush all the entries for the PCID out when we change tasks.
@@ -50,10 +50,10 @@ static void load_new_mm_cr3(pgd_t *pgdir
 		 * do it here, but can only be used if X86_FEATURE_INVPCID is
 		 * available - and many machines support pcid without invpcid.
 		 *
-		 * The line below is a no-op: X86_CR3_PCID_KERN_FLUSH is now 0;
-		 * but keep that line in there in case something changes.
+		 * If X86_CR3_PCID_KERN_FLUSH actually added something, then it
+		 * would be needed in the write_cr3() below - if PCIDs enabled.
 		 */
-		new_mm_cr3 |= X86_CR3_PCID_KERN_FLUSH;
+		BUILD_BUG_ON(X86_CR3_PCID_KERN_FLUSH);
 		kaiser_flush_tlb_on_return_to_user();
 	}
 
author maintainer
#32 lore raw

PATCH 32/37 x86/paravirt: Dont patch flush_tlb_single

In reply to Greg Kroah-Hartman

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

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

From: Thomas Gleixner <[email protected]>

commit a035795499ca1c2bd1928808d1a156eda1420383 upstream

native_flush_tlb_single() will be changed with the upcoming PAGE_TABLE_ISOLATION feature. This requires to have more code in there than INVLPG.

Remove the paravirt patching for it.

---
 arch/x86/kernel/paravirt_patch_64.c |    2 --
 1 file changed, 2 deletions(-)
arch/x86/kernel/paravirt_patch_64.c +0 -2
@@ -9,7 +9,6 @@ DEF_NATIVE(pv_irq_ops, save_fl, "pushfq;
 DEF_NATIVE(pv_mmu_ops, read_cr2, "movq %cr2, %rax");
 DEF_NATIVE(pv_mmu_ops, read_cr3, "movq %cr3, %rax");
 DEF_NATIVE(pv_mmu_ops, write_cr3, "movq %rdi, %cr3");
-DEF_NATIVE(pv_mmu_ops, flush_tlb_single, "invlpg (%rdi)");
 DEF_NATIVE(pv_cpu_ops, clts, "clts");
 DEF_NATIVE(pv_cpu_ops, wbinvd, "wbinvd");
 
@@ -62,7 +61,6 @@ unsigned native_patch(u8 type, u16 clobb
 		PATCH_SITE(pv_mmu_ops, read_cr3);
 		PATCH_SITE(pv_mmu_ops, write_cr3);
 		PATCH_SITE(pv_cpu_ops, clts);
-		PATCH_SITE(pv_mmu_ops, flush_tlb_single);
 		PATCH_SITE(pv_cpu_ops, wbinvd);
 #if defined(CONFIG_PARAVIRT_SPINLOCKS) && defined(CONFIG_QUEUED_SPINLOCKS)
 		case PARAVIRT_PATCH(pv_lock_ops.queued_spin_unlock):

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

author maintainer
#33 lore raw

PATCH 33/37 x86/kaiser: Reenable PARAVIRT

In reply to Greg Kroah-Hartman

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

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

From: Borislav Petkov <[email protected]>

Now that the required bits have been addressed, reenable PARAVIRT.

---
 security/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
security/Kconfig +1 -1
@@ -34,7 +34,7 @@ config SECURITY
 config KAISER
 	bool "Remove the kernel mapping in user mode"
 	default y
-	depends on X86_64 && SMP && !PARAVIRT
+	depends on X86_64 && SMP
 	help
 	  This enforces a strict kernel and user space isolation, in order
 	  to close hardware side channels on kernel address information.
author maintainer
#34 lore raw

PATCH 34/37 kaiser: disabled on Xen PV

In reply to Greg Kroah-Hartman

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

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

From: Jiri Kosina <[email protected]>

Kaiser cannot be used on paravirtualized MMUs (namely reading and writing CR3). This does not work with KAISER as the CR3 switch from and to user space PGD would require to map the whole XEN_PV machinery into both.

More importantly, enabling KAISER on Xen PV doesn't make too much sense, as PV guests use distinct %cr3 values for kernel and user already.

---
 arch/x86/mm/kaiser.c |    5 +++++
 1 file changed, 5 insertions(+)
arch/x86/mm/kaiser.c +5 -0
@@ -264,6 +264,9 @@ void __init kaiser_check_boottime_disabl
 	char arg[5];
 	int ret;
 
+	if (boot_cpu_has(X86_FEATURE_XENPV))
+		goto silent_disable;
+
 	ret = cmdline_find_option(boot_command_line, "pti", arg, sizeof(arg));
 	if (ret > 0) {
 		if (!strncmp(arg, "on", 2))
@@ -291,6 +294,8 @@ enable:
 
 disable:
 	pr_info("Kernel/User page tables isolation: disabled\n");
+
+silent_disable:
 	kaiser_enabled = 0;
 	setup_clear_cpu_cap(X86_FEATURE_KAISER);
 }
author maintainer
#35 lore raw

PATCH 35/37 x86/kaiser: Move feature detection up

In reply to Greg Kroah-Hartman

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

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

From: Borislav Petkov <[email protected]>

... before the first use of kaiser_enabled as otherwise funky things happen:

about to get started...
(XEN) d0v0 Unhandled page fault fault/trap [#14, ec=0000] (XEN) Pagetable walk from ffff88022a449090:
(XEN) L4[0x110] = 0000000229e0e067 0000000000001e0e
(XEN) L3[0x008] = 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S: fault at ffff82d08033fd08 entry.o#create_bounce_frame+0x135/0x14d
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.9.1_02-3.21 x86_64 debug=n Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e033:[<ffffffff81007460>]
(XEN) RFLAGS: 0000000000000286 EM: 1 CONTEXT: pv guest (d0v0)

---
 arch/x86/include/asm/kaiser.h |    2 ++
 arch/x86/kernel/setup.c       |    7 +++++++
 arch/x86/mm/kaiser.c          |    2 --
 3 files changed, 9 insertions(+), 2 deletions(-)
arch/x86/include/asm/kaiser.h +2 -0
@@ -96,8 +96,10 @@ DECLARE_PER_CPU(unsigned long, x86_cr3_p
 extern char __per_cpu_user_mapped_start[], __per_cpu_user_mapped_end[];
 
 extern int kaiser_enabled;
+extern void __init kaiser_check_boottime_disable(void);
 #else
 #define kaiser_enabled	0
+static inline void __init kaiser_check_boottime_disable(void) {}
 #endif /* CONFIG_KAISER */
 
 /*
arch/x86/kernel/setup.c +7 -0
@@ -112,6 +112,7 @@
 #include <asm/alternative.h>
 #include <asm/prom.h>
 #include <asm/microcode.h>
+#include <asm/kaiser.h>
 
 /*
  * max_low_pfn_mapped: highest direct mapped pfn under 4GB
@@ -1016,6 +1017,12 @@ void __init setup_arch(char **cmdline_p)
 	 */
 	init_hypervisor_platform();
 
+	/*
+	 * This needs to happen right after XENPV is set on xen and
+	 * kaiser_enabled is checked below in cleanup_highmap().
+	 */
+	kaiser_check_boottime_disable();
+
 	x86_init.resources.probe_roms();
 
 	/* after parse_early_param, so could debug it */
arch/x86/mm/kaiser.c +0 -2
@@ -311,8 +311,6 @@ void __init kaiser_init(void)
 {
 	int cpu;
 
-	kaiser_check_boottime_disable();
-
 	if (!kaiser_enabled)
 		return;
 
author maintainer
#36 lore raw

PATCH 36/37 KPTI: Rename to PAGE_TABLE_ISOLATION

In reply to Greg Kroah-Hartman

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

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

From: Kees Cook <[email protected]>

This renames CONFIG_KAISER to CONFIG_PAGE_TABLE_ISOLATION.

---
 arch/x86/boot/compressed/misc.h           |    2 +-
 arch/x86/entry/entry_64.S                 |   12 ++++++------
 arch/x86/include/asm/cpufeature.h         |    2 +-
 arch/x86/include/asm/kaiser.h             |   12 ++++++------
 arch/x86/include/asm/pgtable.h            |    4 ++--
 arch/x86/include/asm/pgtable_64.h         |    4 ++--
 arch/x86/include/asm/pgtable_types.h      |    2 +-
 arch/x86/include/asm/tlbflush.h           |    2 +-
 arch/x86/kernel/cpu/perf_event_intel_ds.c |    4 ++--
 arch/x86/kernel/head_64.S                 |    2 +-
 arch/x86/mm/Makefile                      |    2 +-
 include/linux/kaiser.h                    |    6 +++---
 include/linux/percpu-defs.h               |    2 +-
 security/Kconfig                          |    2 +-
 14 files changed, 29 insertions(+), 29 deletions(-)
arch/x86/boot/compressed/misc.h +1 -1
@@ -9,7 +9,7 @@
  */
 #undef CONFIG_PARAVIRT
 #undef CONFIG_PARAVIRT_SPINLOCKS
-#undef CONFIG_KAISER
+#undef CONFIG_PAGE_TABLE_ISOLATION
 #undef CONFIG_KASAN
 
 #include <linux/linkage.h>
arch/x86/entry/entry_64.S +6 -6
@@ -1043,7 +1043,7 @@ ENTRY(paranoid_entry)
 	SWAPGS
 	xorl	%ebx, %ebx
 1:
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 	/*
 	 * We might have come in between a swapgs and a SWITCH_KERNEL_CR3
 	 * on entry, or between a SWITCH_USER_CR3 and a swapgs on exit.
@@ -1083,7 +1083,7 @@ ENTRY(paranoid_exit)
 	DISABLE_INTERRUPTS(CLBR_NONE)
 	TRACE_IRQS_OFF_DEBUG
 	TRACE_IRQS_IRETQ_DEBUG
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 	/* No ALTERNATIVE for X86_FEATURE_KAISER: paranoid_entry sets %ebx */
 	testl	$2, %ebx			/* SWITCH_USER_CR3 needed? */
 	jz	paranoid_exit_no_switch
@@ -1314,7 +1314,7 @@ ENTRY(nmi)
 
 	movq	%rsp, %rdi
 	movq	$-1, %rsi
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 	/* Unconditionally use kernel CR3 for do_nmi() */
 	/* %rax is saved above, so OK to clobber here */
 	ALTERNATIVE "jmp 2f", "movq %cr3, %rax", X86_FEATURE_KAISER
@@ -1328,7 +1328,7 @@ ENTRY(nmi)
 #endif
 	call	do_nmi
 
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 	/*
 	 * Unconditionally restore CR3.  I know we return to
 	 * kernel code that needs user CR3, but do we ever return
@@ -1558,7 +1558,7 @@ end_repeat_nmi:
 1:
 	movq	%rsp, %rdi
 	movq	$-1, %rsi
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 	/* Unconditionally use kernel CR3 for do_nmi() */
 	/* %rax is saved above, so OK to clobber here */
 	ALTERNATIVE "jmp 2f", "movq %cr3, %rax", X86_FEATURE_KAISER
@@ -1574,7 +1574,7 @@ end_repeat_nmi:
 	/* paranoidentry do_nmi, 0; without TRACE_IRQS_OFF */
 	call	do_nmi
 
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 	/*
 	 * Unconditionally restore CR3.  We might be returning to
 	 * kernel code that needs user CR3, like just just before
arch/x86/include/asm/cpufeature.h +1 -1
@@ -201,7 +201,7 @@
 #define X86_FEATURE_INTEL_PT	( 7*32+15) /* Intel Processor Trace */
 
 /* Because the ALTERNATIVE scheme is for members of the X86_FEATURE club... */
-#define X86_FEATURE_KAISER	( 7*32+31) /* CONFIG_KAISER w/o nokaiser */
+#define X86_FEATURE_KAISER	( 7*32+31) /* CONFIG_PAGE_TABLE_ISOLATION w/o nokaiser */
 
 /* Virtualization flags: Linux defined, word 8 */
 #define X86_FEATURE_TPR_SHADOW  ( 8*32+ 0) /* Intel TPR Shadow */
arch/x86/include/asm/kaiser.h +6 -6
@@ -20,7 +20,7 @@
 #define KAISER_SHADOW_PGD_OFFSET 0x1000
 
 #ifdef __ASSEMBLY__
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 
 .macro _SWITCH_TO_KERNEL_CR3 reg
 movq %cr3, \reg
@@ -69,7 +69,7 @@ movq PER_CPU_VAR(unsafe_stack_register_b
 8:
 .endm
 
-#else /* CONFIG_KAISER */
+#else /* CONFIG_PAGE_TABLE_ISOLATION */
 
 .macro SWITCH_KERNEL_CR3
 .endm
@@ -78,11 +78,11 @@ movq PER_CPU_VAR(unsafe_stack_register_b
 .macro SWITCH_KERNEL_CR3_NO_STACK
 .endm
 
-#endif /* CONFIG_KAISER */
+#endif /* CONFIG_PAGE_TABLE_ISOLATION */
 
 #else /* __ASSEMBLY__ */
 
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 /*
  * Upon kernel/user mode switch, it may happen that the address
  * space has to be switched before the registers have been
@@ -100,10 +100,10 @@ extern void __init kaiser_check_boottime
 #else
 #define kaiser_enabled	0
 static inline void __init kaiser_check_boottime_disable(void) {}
-#endif /* CONFIG_KAISER */
+#endif /* CONFIG_PAGE_TABLE_ISOLATION */
 
 /*
- * Kaiser function prototypes are needed even when CONFIG_KAISER is not set,
+ * Kaiser function prototypes are needed even when CONFIG_PAGE_TABLE_ISOLATION is not set,
  * so as to build with tests on kaiser_enabled instead of #ifdefs.
  */
 
arch/x86/include/asm/pgtable.h +2 -2
@@ -18,7 +18,7 @@
 #ifndef __ASSEMBLY__
 #include <asm/x86_init.h>
 
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 extern int kaiser_enabled;
 #else
 #define kaiser_enabled 0
@@ -872,7 +872,7 @@ static inline void pmdp_set_wrprotect(st
 static inline void clone_pgd_range(pgd_t *dst, pgd_t *src, int count)
 {
 	memcpy(dst, src, count * sizeof(pgd_t));
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 	if (kaiser_enabled) {
 		/* Clone the shadow pgd part as well */
 		memcpy(native_get_shadow_pgd(dst),
arch/x86/include/asm/pgtable_64.h +2 -2
@@ -106,7 +106,7 @@ static inline void native_pud_clear(pud_
 	native_set_pud(pud, native_make_pud(0));
 }
 
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 extern pgd_t kaiser_set_shadow_pgd(pgd_t *pgdp, pgd_t pgd);
 
 static inline pgd_t *native_get_shadow_pgd(pgd_t *pgdp)
@@ -127,7 +127,7 @@ static inline pgd_t *native_get_shadow_p
 	BUILD_BUG_ON(1);
 	return NULL;
 }
-#endif /* CONFIG_KAISER */
+#endif /* CONFIG_PAGE_TABLE_ISOLATION */
 
 static inline void native_set_pgd(pgd_t *pgdp, pgd_t pgd)
 {
arch/x86/include/asm/pgtable_types.h +1 -1
@@ -109,7 +109,7 @@
 #define X86_CR3_PCID_MASK       (X86_CR3_PCID_NOFLUSH | X86_CR3_PCID_ASID_MASK)
 #define X86_CR3_PCID_ASID_KERN  (_AC(0x0,UL))
 
-#if defined(CONFIG_KAISER) && defined(CONFIG_X86_64)
+#if defined(CONFIG_PAGE_TABLE_ISOLATION) && defined(CONFIG_X86_64)
 /* Let X86_CR3_PCID_ASID_USER be usable for the X86_CR3_PCID_NOFLUSH bit */
 #define X86_CR3_PCID_ASID_USER	(_AC(0x80,UL))
 
arch/x86/include/asm/tlbflush.h +1 -1
@@ -135,7 +135,7 @@ static inline void cr4_set_bits_and_upda
  * Declare a couple of kaiser interfaces here for convenience,
  * to avoid the need for asm/kaiser.h in unexpected places.
  */
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 extern int kaiser_enabled;
 extern void kaiser_setup_pcid(void);
 extern void kaiser_flush_tlb_on_return_to_user(void);
arch/x86/kernel/cpu/perf_event_intel_ds.c +2 -2
@@ -274,7 +274,7 @@ static DEFINE_PER_CPU(void *, insn_buffe
 
 static void *dsalloc(size_t size, gfp_t flags, int node)
 {
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 	unsigned int order = get_order(size);
 	struct page *page;
 	unsigned long addr;
@@ -295,7 +295,7 @@ static void *dsalloc(size_t size, gfp_t
 
 static void dsfree(const void *buffer, size_t size)
 {
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 	if (!buffer)
 		return;
 	kaiser_remove_mapping((unsigned long)buffer, size);
arch/x86/kernel/head_64.S +1 -1
@@ -441,7 +441,7 @@ early_idt_ripmsg:
 	.balign	PAGE_SIZE; \
 GLOBAL(name)
 
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 /*
  * Each PGD needs to be 8k long and 8k aligned.  We do not
  * ever go out to userspace with these, so we do not
arch/x86/mm/Makefile +1 -1
@@ -32,4 +32,4 @@ obj-$(CONFIG_ACPI_NUMA)		+= srat.o
 obj-$(CONFIG_NUMA_EMU)		+= numa_emulation.o
 
 obj-$(CONFIG_X86_INTEL_MPX)	+= mpx.o
-obj-$(CONFIG_KAISER)		+= kaiser.o
+obj-$(CONFIG_PAGE_TABLE_ISOLATION)		+= kaiser.o
include/linux/kaiser.h +3 -3
@@ -1,7 +1,7 @@
 #ifndef _LINUX_KAISER_H
 #define _LINUX_KAISER_H
 
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 #include <asm/kaiser.h>
 
 static inline int kaiser_map_thread_stack(void *stack)
@@ -24,7 +24,7 @@ static inline void kaiser_unmap_thread_s
 #else
 
 /*
- * These stubs are used whenever CONFIG_KAISER is off, which
+ * These stubs are used whenever CONFIG_PAGE_TABLE_ISOLATION is off, which
  * includes architectures that support KAISER, but have it disabled.
  */
 
@@ -48,5 +48,5 @@ static inline void kaiser_unmap_thread_s
 {
 }
 
-#endif /* !CONFIG_KAISER */
+#endif /* !CONFIG_PAGE_TABLE_ISOLATION */
 #endif /* _LINUX_KAISER_H */
include/linux/percpu-defs.h +1 -1
@@ -35,7 +35,7 @@
 
 #endif
 
-#ifdef CONFIG_KAISER
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
 #define USER_MAPPED_SECTION "..user_mapped"
 #else
 #define USER_MAPPED_SECTION ""
security/Kconfig +1 -1
@@ -31,7 +31,7 @@ config SECURITY
 
 	  If you are unsure how to answer this question, answer N.
 
-config KAISER
+config PAGE_TABLE_ISOLATION
 	bool "Remove the kernel mapping in user mode"
 	default y
 	depends on X86_64 && SMP
author maintainer
#37 lore raw

PATCH 37/37 KPTI: Report when enabled

In reply to Greg Kroah-Hartman

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

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

From: Kees Cook <[email protected]>

Make sure dmesg reports when KPTI is enabled.

---
 arch/x86/mm/kaiser.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
arch/x86/mm/kaiser.c +6 -1
@@ -11,6 +11,9 @@
 #include <linux/uaccess.h>
 #include <linux/ftrace.h>
 
+#undef pr_fmt
+#define pr_fmt(fmt)     "Kernel/User page tables isolation: " fmt
+
 #include <asm/kaiser.h>
 #include <asm/tlbflush.h>	/* to verify its kaiser declarations */
 #include <asm/pgtable.h>
@@ -293,7 +296,7 @@ enable:
 	return;
 
 disable:
-	pr_info("Kernel/User page tables isolation: disabled\n");
+	pr_info("disabled\n");
 
 silent_disable:
 	kaiser_enabled = 0;
@@ -353,6 +356,8 @@ void __init kaiser_init(void)
 	kaiser_add_user_map_early(&debug_idt_table,
 				  sizeof(gate_desc) * NR_VECTORS,
 				  __PAGE_KERNEL);
+
+	pr_info("enabled\n");
 }
 
 /* Add a mapping to the shadow mapping, and synchronize the mappings */
#38 lore raw
In reply to Greg Kroah-Hartman
Quoted 176 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.110-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 4.4.110-rc1

Kees Cook <[email protected]>
KPTI: Report when enabled

Kees Cook <[email protected]>
KPTI: Rename to PAGE_TABLE_ISOLATION

Borislav Petkov <[email protected]>
x86/kaiser: Move feature detection up

Jiri Kosina <[email protected]>
kaiser: disabled on Xen PV

Borislav Petkov <[email protected]>
x86/kaiser: Reenable PARAVIRT

Thomas Gleixner <[email protected]>
x86/paravirt: Dont patch flush_tlb_single

Hugh Dickins <[email protected]>
kaiser: kaiser_flush_tlb_on_return_to_user() check PCID

Hugh Dickins <[email protected]>
kaiser: asm/tlbflush.h handle noPGE at lower level

Hugh Dickins <[email protected]>
kaiser: drop is_atomic arg to kaiser_pagetable_walk()

Hugh Dickins <[email protected]>
kaiser: use ALTERNATIVE instead of x86_cr3_pcid_noflush

Borislav Petkov <[email protected]>
x86/kaiser: Check boottime cmdline params

Borislav Petkov <[email protected]>
x86/kaiser: Rename and simplify X86_FEATURE_KAISER handling

Hugh Dickins <[email protected]>
kaiser: add "nokaiser" boot option, using ALTERNATIVE

Hugh Dickins <[email protected]>
kaiser: fix unlikely error in alloc_ldt_struct()

Hugh Dickins <[email protected]>
kaiser: _pgd_alloc() without __GFP_REPEAT to avoid stalls

Hugh Dickins <[email protected]>
kaiser: paranoid_entry pass cr3 need to paranoid_exit

Hugh Dickins <[email protected]>

    kaiser: x86_cr3_pcid_noflush and x86_cr3_pcid_user

Hugh Dickins <[email protected]>
kaiser: PCID 0 for kernel and 128 for user

Hugh Dickins <[email protected]>
kaiser: load_new_mm_cr3() let SWITCH_USER_CR3 flush user

Dave Hansen <[email protected]>
kaiser: enhanced by kernel and user PCIDs

Hugh Dickins <[email protected]>
kaiser: vmstat show NR_KAISERTABLE as nr_overhead

Hugh Dickins <[email protected]>
kaiser: delete KAISER_REAL_SWITCH option

Hugh Dickins <[email protected]>

    kaiser: name that 0x1000 KAISER_SHADOW_PGD_OFFSET

Hugh Dickins <[email protected]>
kaiser: cleanups while trying for gold link

Hugh Dickins <[email protected]>
kaiser: kaiser_remove_mapping() move along the pgd

Hugh Dickins <[email protected]>
kaiser: tidied up kaiser_add/remove_mapping slightly

Hugh Dickins <[email protected]>
kaiser: tidied up asm/kaiser.h somewhat

Hugh Dickins <[email protected]>
kaiser: ENOMEM if kaiser_pagetable_walk() NULL

Hugh Dickins <[email protected]>
kaiser: fix perf crashes

Hugh Dickins <[email protected]>
kaiser: fix regs to do_nmi() ifndef CONFIG_KAISER

Hugh Dickins <[email protected]>
kaiser: KAISER depends on SMP

Hugh Dickins <[email protected]>
kaiser: fix build and FIXME in alloc_ldt_struct()

Hugh Dickins <[email protected]>
kaiser: stack map PAGE_SIZE at THREAD_SIZE-PAGE_SIZE

Hugh Dickins <[email protected]>
kaiser: do not set _PAGE_NX on pgd_none

Dave Hansen <[email protected]>
kaiser: merged update

Richard Fellner <[email protected]>
KAISER: Kernel Address Isolation

Tom Lendacky <[email protected]>
x86/boot: Add early cmdline parsing for options with arguments

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

Diffstat:

 Documentation/kernel-parameters.txt         |   8 +
 Makefile                                    |   4 +-
 arch/x86/boot/compressed/misc.h             |   1 +
 arch/x86/entry/entry_64.S                   | 164 ++++++++--
 arch/x86/entry/entry_64_compat.S            |   7 +
 arch/x86/include/asm/cmdline.h              |   2 +
 arch/x86/include/asm/cpufeature.h           |   4 +
 arch/x86/include/asm/desc.h                 |   2 +-
 arch/x86/include/asm/hw_irq.h               |   2 +-
 arch/x86/include/asm/kaiser.h               | 141 +++++++++
 arch/x86/include/asm/pgtable.h              |  28 +-
 arch/x86/include/asm/pgtable_64.h           |  25 +-
 arch/x86/include/asm/pgtable_types.h        |  29 +-
 arch/x86/include/asm/processor.h            |   2 +-
 arch/x86/include/asm/tlbflush.h             |  74 ++++-
 arch/x86/include/uapi/asm/processor-flags.h |   3 +-
 arch/x86/kernel/cpu/common.c                |  28 +-
 arch/x86/kernel/cpu/perf_event_intel_ds.c   |  57 +++-
 arch/x86/kernel/espfix_64.c                 |  10 +
 arch/x86/kernel/head_64.S                   |  35 ++-
 arch/x86/kernel/irqinit.c                   |   2 +-
 arch/x86/kernel/ldt.c                       |  25 +-
 arch/x86/kernel/paravirt_patch_64.c         |   2 -
 arch/x86/kernel/process.c                   |   2 +-
 arch/x86/kernel/setup.c                     |   7 +
 arch/x86/kernel/tracepoint.c                |   2 +
 arch/x86/kvm/x86.c                          |   3 +-
 arch/x86/lib/cmdline.c                      | 105 +++++++
 arch/x86/mm/Makefile                        |   1 +
 arch/x86/mm/init.c                          |   2 +-
 arch/x86/mm/init_64.c                       |  10 +
 arch/x86/mm/kaiser.c                        | 455 ++++++++++++++++++++++++++++
 arch/x86/mm/pageattr.c                      |  63 +++-
 arch/x86/mm/pgtable.c                       |  16 +-
 arch/x86/mm/tlb.c                           |  39 ++-
 include/asm-generic/vmlinux.lds.h           |   7 +
Quoted 10 lines
 include/linux/kaiser.h                      |  52 ++++
 include/linux/mmzone.h                      |   3 +-
 include/linux/percpu-defs.h                 |  32 +-
 init/main.c                                 |   2 +
 kernel/fork.c                               |   6 +
 mm/vmstat.c                                 |   1 +
 security/Kconfig                            |  10 +
 43 files changed, 1375 insertions(+), 98 deletions(-)

Not that my feedback will matter much on this release since Pixel 2 XL is an arm64 device but merged, compiled, and flashed successfully.

The changes to kernel/fork.c had to be slightly adjusted for Google's tree due to their addition of mainline commit b235beea9e99 ("Clarify naming of thread info/stack allocators").

No noticeable issues in general use or dmesg.

Thanks!
Nathan

author maintainer
#39 lore raw
Quoted 2 lines · Nathan Chancellor

Not that my feedback will matter much on this release since Pixel 2 XL is an arm64 device but merged, compiled, and flashed successfully.

Hey, it's good to know I didn't break anything :)

Quoted 3 lines

The changes to kernel/fork.c had to be slightly adjusted for Google's tree due to their addition of mainline commit b235beea9e99 ("Clarify naming of thread info/stack allocators").

Ah, good to know, I'll watch out for that when I do the andoid-common tree merges.

Thanks again for testing and letting me know.

greg k-h

Tested-by on the v1 series
#40 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
        kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.110-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE:
Retested 20 Iterations on two devices and all 40 times test completed successfully.
Which confirms this is an intermittent timing failure.
For the internal investigation and record the bug has been reported. LKFT:stable-rc 4.4.110-rc1: x15: LTP poll02 FAIL: poll() slept for too long (intermittent)
https://bugs.linaro.org/show_bug.cgi?id=3566

Summary
------------------------------------------------------------------------

kernel: 4.4.110-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 99abd6cdd65e984d89c8565508a7a96ea0fce179
git describe: v4.4.109-38-g99abd6cdd65e
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.109-38-g99abd6cdd65e

No Regressions (compared to build v4.4.109)
------------------------------------------------------------------------

Boards, architectures and test suites:
-------------------------------------

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 32, skip: 29
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 984, skip: 124
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 31, skip: 29
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - fail: 1, pass: 1034, skip: 67
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - pass: 44, skip: 32
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1013, skip: 117
* ltp-timers-tests - pass: 12,

Hikey board test results,

Summary
------------------------------------------------------------------------

kernel: 4.4.110-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.110-rc1-hikey-20180103-95
git commit: 0769c4b4aafd63e5d73b6d67f6fe93abcff67cdc
git describe: 4.4.110-rc1-hikey-20180103-95
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.110-rc1-hikey-20180103-95

No regressions (compared to build 4.4.110-rc1-hikey-20180103-94)

Boards, architectures and test suites:
-------------------------------------

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 30, skip: 31
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 980, skip: 124
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

#41 lore raw
In reply to Greg Kroah-Hartman
stable-rc/linux-4.4.y boot: 100 boots: 4 failed, 93 passed with 1 offline, 2 conflicts (v4.4.109-38-g99abd6cdd65e)

stable-rc/linux-4.4.y boot: 100 boots: 4 failed, 93 passed with 1 offline, 2 conflicts (v4.4.109-38-g99abd6cdd65e)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.109-38-g99abd6cdd65e/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.109-38-g99abd6cdd65e/

Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.109-38-g99abd6cdd65e
Git Commit: 99abd6cdd65e984d89c8565508a7a96ea0fce179
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 53 unique boards, 19 SoC families, 16 builds out of 178

Boot Regressions Detected:

arm:

    exynos_defconfig:
        exynos5422-odroidxu3:
            lab-collabora: failing since 58 days (last pass: v4.4.95-21-g32458fcb7bd6 - first fail: v4.4.96-41-g336421367b9c)

    multi_v7_defconfig:
        armada-xp-linksys-mamba:
            lab-free-electrons: new failure (last pass: v4.4.109-36-g8b381424010c)
        tegra124-nyan-big:
            lab-collabora: failing since 1 day (last pass: v4.4.109 - first fail: v4.4.109-36-g8b381424010c)

    tegra_defconfig:
        tegra124-nyan-big:
            lab-collabora: failing since 1 day (last pass: v4.4.108-65-g57856049c0f8 - first fail: v4.4.109)

Boot Failures Detected:

arm:

multi_v7_defconfig
armada-xp-linksys-mamba: 1 failed lab
tegra124-nyan-big: 1 failed lab

exynos_defconfig
exynos5422-odroidxu3_rootfs:nfs: 1 failed lab

tegra_defconfig
tegra124-nyan-big: 1 failed lab

Offline Platforms:

arm:

davinci_all_defconfig:
dm365evm,legacy: 1 offline lab

Conflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)

arm:

    multi_v7_defconfig:
        exynos5422-odroidxu3:
            lab-baylibre-seattle: PASS
            lab-collabora: FAIL

    exynos_defconfig:
        exynos5422-odroidxu3:
            lab-baylibre-seattle: PASS
            lab-collabora: FAIL

---
For more info write to <[email protected]>

#42 lore raw
Quoted 11 lines · kernelci.org bot

stable-rc/linux-4.4.y boot: 100 boots: 4 failed, 93 passed with 1 offline, 2 conflicts (v4.4.109-38-g99abd6cdd65e)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.109-38-g99abd6cdd65e/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.109-38-g99abd6cdd65e/

Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.109-38-g99abd6cdd65e
Git Commit: 99abd6cdd65e984d89c8565508a7a96ea0fce179
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 53 unique boards, 19 SoC families, 16 builds out of 178

TL;DR; All is well.

Quoted 7 lines

Boot Regressions Detected:

arm:

    exynos_defconfig:
        exynos5422-odroidxu3:
            lab-collabora: failing since 58 days (last pass: v4.4.95-21-g32458fcb7bd6 - first fail: v4.4.96-41-g336421367b9c)

Long standing issue in lab-collabora (passing in other labs) Guillaume?

Quoted 3 lines
    multi_v7_defconfig:
        armada-xp-linksys-mamba:
            lab-free-electrons: new failure (last pass: v4.4.109-36-g8b381424010c)

Not a kerel issue, bootROM fails to start bootloader. I pinged lab owners (Free Electrons)

Quoted 6 lines
        tegra124-nyan-big:
            lab-collabora: failing since 1 day (last pass: v4.4.109 - first fail: v4.4.109-36-g8b381424010c)

    tegra_defconfig:
        tegra124-nyan-big:
            lab-collabora: failing since 1 day (last pass: v4.4.108-65-g57856049c0f8 - first fail: v4.4.109)

This one is booting fine, but the command to power-off the board is timing out, resulting in a failure report.

Kevin

#43 lore raw
Quoted 18 lines · Kevin Hilman
Quoted 11 lines · kernelci.org bot

stable-rc/linux-4.4.y boot: 100 boots: 4 failed, 93 passed with 1 offline, 2 conflicts (v4.4.109-38-g99abd6cdd65e)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.109-38-g99abd6cdd65e/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.109-38-g99abd6cdd65e/

Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.109-38-g99abd6cdd65e
Git Commit: 99abd6cdd65e984d89c8565508a7a96ea0fce179
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 53 unique boards, 19 SoC families, 16 builds out of 178

TL;DR; All is well.

Quoted 2 lines

Boot Regressions Detected:

Quoted 7 lines
Quoted 5 lines

arm:

     exynos_defconfig:
         exynos5422-odroidxu3:
             lab-collabora: failing since 58 days (last pass: v4.4.95-21-g32458fcb7bd6 - first fail: v4.4.96-41-g336421367b9c)

Long standing issue in lab-collabora (passing in other labs) Guillaume?

This should be fixed now, with a tweak to the device config to enable relocating the ramdisk and dtb:

    https://review.linaro.org/#/c/23238/
Quoted 10 lines
Quoted 3 lines
     multi_v7_defconfig:
         armada-xp-linksys-mamba:
             lab-free-electrons: new failure (last pass: v4.4.109-36-g8b381424010c)

Not a kerel issue, bootROM fails to start bootloader. I pinged lab owners (Free Electrons)

Quoted 3 lines
         tegra124-nyan-big:
             lab-collabora: failing since 1 day (last pass: v4.4.109 - first fail: v4.4.109-36-g8b381424010c)
Quoted 6 lines
Quoted 3 lines
     tegra_defconfig:
         tegra124-nyan-big:
             lab-collabora: failing since 1 day (last pass: v4.4.108-65-g57856049c0f8 - first fail: v4.4.109)

This one is booting fine, but the command to power-off the board is timing out, resulting in a failure report.

Indeed, this was due to a crash of the lavapdu daemon - it's back on track now.

(On a side note, the tegra124-nyan-big is still failing to boot in mainline due to a genuine kernel driver issue.)

Guillaume

#44 lore raw
In reply to Greg Kroah-Hartman

I am getting the following panic when trying to boot 4.4.110rc1 on Intel(R) Xeon(R) CPU E5-2630:

[    5.923489] BUG: unable to handle kernel NULL pointer dereference
at 000000000000000d
[    5.932259] IP: [<ffffffff810e70d2>] dyntick_save_progress_counter+0x12/0x50
[    5.940142] PGD 0
[    5.942400] Oops: 0002 [#1] SMP
[    5.946023] Modules linked in:
[    5.949448] CPU: 5 PID: 8 Comm: rcu_sched Not tainted
4.4.110-rc1_pt_linux-4.4.110rc1 #1
[    5.958484] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
[    5.969552] task: ffff881ff2f1ab00 ti: ffff881ff2f24000 task.ti:
ffff881ff2f24000
[    5.977905] RIP: 0010:[<ffffffff810e70d2>]  [<ffffffff810e70d2>]
dyntick_save_progress_counter+0x12/0x50
[    5.988505] RSP: 0000:ffff881ff2f27dc0  EFLAGS: 00010046
[    5.994434] RAX: 0000000000000001 RBX: ffffffff81b02140 RCX: ffff883fec768000
[    6.002403] RDX: 0000000000000000 RSI: ffff881ff2f27e5f RDI: ffff88407e958140
[    6.010368] RBP: ffff881ff2f27dc0 R08: ffff881ff2f27e78 R09: 000000016110f359
[    6.018333] R10: 0000000000000b10 R11: 0000000000000000 R12: ffffffff81b02140
[    6.026297] R13: 00000000ffffffdf R14: 0000000000000021 R15: 0000000200000000
[    6.034262] FS:  0000000000000000(0000) GS:ffff881fff940000(0000)
knlGS:0000000000000000
[    6.043293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.049707] CR2: 000000000000000d CR3: 0000000001aa6000 CR4: 0000000000360670
[    6.057672] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    6.065638] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    6.073603] Stack:
[    6.075847]  ffff881ff2f27e18 ffffffff810e8fac 0000000000000202
ffff881ff2f27e60
[    6.084158]  ffff881ff2f27e5f ffffffff810e70c0 ffffffff81b02140
ffffffff81b127a0
[    6.092465]  0000000000000001 0000000000000000 0000000000000003
ffff881ff2f27eb8
[    6.100768] Call Trace:
[    6.103501]  [<ffffffff810e8fac>] force_qs_rnp+0xdc/0x150
[    6.109527]  [<ffffffff810e70c0>] ? rcu_start_gp+0x70/0x70
[    6.115654]  [<ffffffff810ea118>] rcu_gp_kthread+0x468/0x9b0
[    6.121976]  [<ffffffff810c9190>] ? prepare_to_wait_event+0xf0/0xf0
[    6.128973]  [<ffffffff810e9cb0>] ? rcu_process_callbacks+0x5f0/0x5f0
[    6.136167]  [<ffffffff810a4a25>] kthread+0xe5/0x100
[    6.141710]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60
[    6.147840]  [<ffffffff81714e8f>] ret_from_fork+0x3f/0x70
[    6.153868]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60

I tried to bisect the problem, but when I try to boot only with:
"KAISER: Kernel Address Isolation" machine hangs during boot and reboots without any panic message.

4.4.109 boots fine
4.9.75rc1 also boots fine.

Thank you,
Pavel

Quoted 186 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

        kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.110-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 4.4.110-rc1

Kees Cook <[email protected]>
KPTI: Report when enabled

Kees Cook <[email protected]>
KPTI: Rename to PAGE_TABLE_ISOLATION

Borislav Petkov <[email protected]>
x86/kaiser: Move feature detection up

Jiri Kosina <[email protected]>
kaiser: disabled on Xen PV

Borislav Petkov <[email protected]>
x86/kaiser: Reenable PARAVIRT

Thomas Gleixner <[email protected]>
x86/paravirt: Dont patch flush_tlb_single

Hugh Dickins <[email protected]>
kaiser: kaiser_flush_tlb_on_return_to_user() check PCID

Hugh Dickins <[email protected]>
kaiser: asm/tlbflush.h handle noPGE at lower level

Hugh Dickins <[email protected]>
kaiser: drop is_atomic arg to kaiser_pagetable_walk()

Hugh Dickins <[email protected]>
kaiser: use ALTERNATIVE instead of x86_cr3_pcid_noflush

Borislav Petkov <[email protected]>
x86/kaiser: Check boottime cmdline params

Borislav Petkov <[email protected]>
x86/kaiser: Rename and simplify X86_FEATURE_KAISER handling

Hugh Dickins <[email protected]>
kaiser: add "nokaiser" boot option, using ALTERNATIVE

Hugh Dickins <[email protected]>
kaiser: fix unlikely error in alloc_ldt_struct()

Hugh Dickins <[email protected]>
kaiser: _pgd_alloc() without __GFP_REPEAT to avoid stalls

Hugh Dickins <[email protected]>
kaiser: paranoid_entry pass cr3 need to paranoid_exit

Hugh Dickins <[email protected]>

    kaiser: x86_cr3_pcid_noflush and x86_cr3_pcid_user

Hugh Dickins <[email protected]>
kaiser: PCID 0 for kernel and 128 for user

Hugh Dickins <[email protected]>
kaiser: load_new_mm_cr3() let SWITCH_USER_CR3 flush user

Dave Hansen <[email protected]>
kaiser: enhanced by kernel and user PCIDs

Hugh Dickins <[email protected]>
kaiser: vmstat show NR_KAISERTABLE as nr_overhead

Hugh Dickins <[email protected]>
kaiser: delete KAISER_REAL_SWITCH option

Hugh Dickins <[email protected]>

    kaiser: name that 0x1000 KAISER_SHADOW_PGD_OFFSET

Hugh Dickins <[email protected]>
kaiser: cleanups while trying for gold link

Hugh Dickins <[email protected]>
kaiser: kaiser_remove_mapping() move along the pgd

Hugh Dickins <[email protected]>
kaiser: tidied up kaiser_add/remove_mapping slightly

Hugh Dickins <[email protected]>
kaiser: tidied up asm/kaiser.h somewhat

Hugh Dickins <[email protected]>
kaiser: ENOMEM if kaiser_pagetable_walk() NULL

Hugh Dickins <[email protected]>
kaiser: fix perf crashes

Hugh Dickins <[email protected]>
kaiser: fix regs to do_nmi() ifndef CONFIG_KAISER

Hugh Dickins <[email protected]>
kaiser: KAISER depends on SMP

Hugh Dickins <[email protected]>
kaiser: fix build and FIXME in alloc_ldt_struct()

Hugh Dickins <[email protected]>
kaiser: stack map PAGE_SIZE at THREAD_SIZE-PAGE_SIZE

Hugh Dickins <[email protected]>
kaiser: do not set _PAGE_NX on pgd_none

Dave Hansen <[email protected]>
kaiser: merged update

Richard Fellner <[email protected]>
KAISER: Kernel Address Isolation

Tom Lendacky <[email protected]>
x86/boot: Add early cmdline parsing for options with arguments

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

Diffstat:

 Documentation/kernel-parameters.txt         |   8 +
 Makefile                                    |   4 +-
 arch/x86/boot/compressed/misc.h             |   1 +
 arch/x86/entry/entry_64.S                   | 164 ++++++++--
 arch/x86/entry/entry_64_compat.S            |   7 +
 arch/x86/include/asm/cmdline.h              |   2 +
 arch/x86/include/asm/cpufeature.h           |   4 +
 arch/x86/include/asm/desc.h                 |   2 +-
 arch/x86/include/asm/hw_irq.h               |   2 +-
 arch/x86/include/asm/kaiser.h               | 141 +++++++++
 arch/x86/include/asm/pgtable.h              |  28 +-
 arch/x86/include/asm/pgtable_64.h           |  25 +-
 arch/x86/include/asm/pgtable_types.h        |  29 +-
 arch/x86/include/asm/processor.h            |   2 +-
 arch/x86/include/asm/tlbflush.h             |  74 ++++-
 arch/x86/include/uapi/asm/processor-flags.h |   3 +-
 arch/x86/kernel/cpu/common.c                |  28 +-
 arch/x86/kernel/cpu/perf_event_intel_ds.c   |  57 +++-
 arch/x86/kernel/espfix_64.c                 |  10 +
 arch/x86/kernel/head_64.S                   |  35 ++-
 arch/x86/kernel/irqinit.c                   |   2 +-
 arch/x86/kernel/ldt.c                       |  25 +-
 arch/x86/kernel/paravirt_patch_64.c         |   2 -
 arch/x86/kernel/process.c                   |   2 +-
 arch/x86/kernel/setup.c                     |   7 +
 arch/x86/kernel/tracepoint.c                |   2 +
 arch/x86/kvm/x86.c                          |   3 +-
 arch/x86/lib/cmdline.c                      | 105 +++++++
 arch/x86/mm/Makefile                        |   1 +
 arch/x86/mm/init.c                          |   2 +-
 arch/x86/mm/init_64.c                       |  10 +
 arch/x86/mm/kaiser.c                        | 455 ++++++++++++++++++++++++++++
 arch/x86/mm/pageattr.c                      |  63 +++-
 arch/x86/mm/pgtable.c                       |  16 +-
 arch/x86/mm/tlb.c                           |  39 ++-
 include/asm-generic/vmlinux.lds.h           |   7 +
 include/linux/kaiser.h                      |  52 ++++
 include/linux/mmzone.h                      |   3 +-
 include/linux/percpu-defs.h                 |  32 +-
 init/main.c                                 |   2 +
 kernel/fork.c                               |   6 +
 mm/vmstat.c                                 |   1 +
 security/Kconfig                            |  10 +
 43 files changed, 1375 insertions(+), 98 deletions(-)
Signature · 1 line
Life Is BeAuTifuL :)
author maintainer
#45 lore raw
Quoted 47 lines · Pavel Tatashin

I am getting the following panic when trying to boot 4.4.110rc1 on Intel(R) Xeon(R) CPU E5-2630:

[    5.923489] BUG: unable to handle kernel NULL pointer dereference
at 000000000000000d
[    5.932259] IP: [<ffffffff810e70d2>] dyntick_save_progress_counter+0x12/0x50
[    5.940142] PGD 0
[    5.942400] Oops: 0002 [#1] SMP
[    5.946023] Modules linked in:
[    5.949448] CPU: 5 PID: 8 Comm: rcu_sched Not tainted
4.4.110-rc1_pt_linux-4.4.110rc1 #1
[    5.958484] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
[    5.969552] task: ffff881ff2f1ab00 ti: ffff881ff2f24000 task.ti:
ffff881ff2f24000
[    5.977905] RIP: 0010:[<ffffffff810e70d2>]  [<ffffffff810e70d2>]
dyntick_save_progress_counter+0x12/0x50
[    5.988505] RSP: 0000:ffff881ff2f27dc0  EFLAGS: 00010046
[    5.994434] RAX: 0000000000000001 RBX: ffffffff81b02140 RCX: ffff883fec768000
[    6.002403] RDX: 0000000000000000 RSI: ffff881ff2f27e5f RDI: ffff88407e958140
[    6.010368] RBP: ffff881ff2f27dc0 R08: ffff881ff2f27e78 R09: 000000016110f359
[    6.018333] R10: 0000000000000b10 R11: 0000000000000000 R12: ffffffff81b02140
[    6.026297] R13: 00000000ffffffdf R14: 0000000000000021 R15: 0000000200000000
[    6.034262] FS:  0000000000000000(0000) GS:ffff881fff940000(0000)
knlGS:0000000000000000
[    6.043293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.049707] CR2: 000000000000000d CR3: 0000000001aa6000 CR4: 0000000000360670
[    6.057672] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    6.065638] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    6.073603] Stack:
[    6.075847]  ffff881ff2f27e18 ffffffff810e8fac 0000000000000202
ffff881ff2f27e60
[    6.084158]  ffff881ff2f27e5f ffffffff810e70c0 ffffffff81b02140
ffffffff81b127a0
[    6.092465]  0000000000000001 0000000000000000 0000000000000003
ffff881ff2f27eb8
[    6.100768] Call Trace:
[    6.103501]  [<ffffffff810e8fac>] force_qs_rnp+0xdc/0x150
[    6.109527]  [<ffffffff810e70c0>] ? rcu_start_gp+0x70/0x70
[    6.115654]  [<ffffffff810ea118>] rcu_gp_kthread+0x468/0x9b0
[    6.121976]  [<ffffffff810c9190>] ? prepare_to_wait_event+0xf0/0xf0
[    6.128973]  [<ffffffff810e9cb0>] ? rcu_process_callbacks+0x5f0/0x5f0
[    6.136167]  [<ffffffff810a4a25>] kthread+0xe5/0x100
[    6.141710]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60
[    6.147840]  [<ffffffff81714e8f>] ret_from_fork+0x3f/0x70
[    6.153868]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60
Quoted 6 lines

I tried to bisect the problem, but when I try to boot only with:
"KAISER: Kernel Address Isolation" machine hangs during boot and reboots without any panic message.

4.4.109 boots fine
4.9.75rc1 also boots fine.

Hm, so I'm guessing 4.15-rc6 also works?

Odd that 4.9.75-rc1 fails.

Adding Jiri and Hugh and Dave here to see if they have seen this before...

thanks,

greg k-h

#46 lore raw
Quoted 52 lines · Greg Kroah-Hartman
Quoted 51 lines · Pavel Tatashin

I am getting the following panic when trying to boot 4.4.110rc1 on Intel(R) Xeon(R) CPU E5-2630:

[    5.923489] BUG: unable to handle kernel NULL pointer dereference
at 000000000000000d
[    5.932259] IP: [<ffffffff810e70d2>] dyntick_save_progress_counter+0x12/0x50
[    5.940142] PGD 0
[    5.942400] Oops: 0002 [#1] SMP
[    5.946023] Modules linked in:
[    5.949448] CPU: 5 PID: 8 Comm: rcu_sched Not tainted
4.4.110-rc1_pt_linux-4.4.110rc1 #1
[    5.958484] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
[    5.969552] task: ffff881ff2f1ab00 ti: ffff881ff2f24000 task.ti:
ffff881ff2f24000
[    5.977905] RIP: 0010:[<ffffffff810e70d2>]  [<ffffffff810e70d2>]
dyntick_save_progress_counter+0x12/0x50
[    5.988505] RSP: 0000:ffff881ff2f27dc0  EFLAGS: 00010046
[    5.994434] RAX: 0000000000000001 RBX: ffffffff81b02140 RCX: ffff883fec768000
[    6.002403] RDX: 0000000000000000 RSI: ffff881ff2f27e5f RDI: ffff88407e958140
[    6.010368] RBP: ffff881ff2f27dc0 R08: ffff881ff2f27e78 R09: 000000016110f359
[    6.018333] R10: 0000000000000b10 R11: 0000000000000000 R12: ffffffff81b02140
[    6.026297] R13: 00000000ffffffdf R14: 0000000000000021 R15: 0000000200000000
[    6.034262] FS:  0000000000000000(0000) GS:ffff881fff940000(0000)
knlGS:0000000000000000
[    6.043293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.049707] CR2: 000000000000000d CR3: 0000000001aa6000 CR4: 0000000000360670
[    6.057672] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    6.065638] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    6.073603] Stack:
[    6.075847]  ffff881ff2f27e18 ffffffff810e8fac 0000000000000202
ffff881ff2f27e60
[    6.084158]  ffff881ff2f27e5f ffffffff810e70c0 ffffffff81b02140
ffffffff81b127a0
[    6.092465]  0000000000000001 0000000000000000 0000000000000003
ffff881ff2f27eb8
[    6.100768] Call Trace:
[    6.103501]  [<ffffffff810e8fac>] force_qs_rnp+0xdc/0x150
[    6.109527]  [<ffffffff810e70c0>] ? rcu_start_gp+0x70/0x70
[    6.115654]  [<ffffffff810ea118>] rcu_gp_kthread+0x468/0x9b0
[    6.121976]  [<ffffffff810c9190>] ? prepare_to_wait_event+0xf0/0xf0
[    6.128973]  [<ffffffff810e9cb0>] ? rcu_process_callbacks+0x5f0/0x5f0
[    6.136167]  [<ffffffff810a4a25>] kthread+0xe5/0x100
[    6.141710]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60
[    6.147840]  [<ffffffff81714e8f>] ret_from_fork+0x3f/0x70
[    6.153868]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60

I tried to bisect the problem, but when I try to boot only with:
"KAISER: Kernel Address Isolation" machine hangs during boot and reboots without any panic message.

Quoted 7 lines
Quoted 2 lines

4.4.109 boots fine
4.9.75rc1 also boots fine.

Hm, so I'm guessing 4.15-rc6 also works?

Odd that 4.9.75-rc1 fails.

I thought the above says that it boots fine ?

Guenter

author maintainer
#47 lore raw
Quoted 53 lines · Guenter Roeck
Quoted 52 lines · Greg Kroah-Hartman
Quoted 51 lines · Pavel Tatashin

I am getting the following panic when trying to boot 4.4.110rc1 on Intel(R) Xeon(R) CPU E5-2630:

[    5.923489] BUG: unable to handle kernel NULL pointer dereference
at 000000000000000d
[    5.932259] IP: [<ffffffff810e70d2>] dyntick_save_progress_counter+0x12/0x50
[    5.940142] PGD 0
[    5.942400] Oops: 0002 [#1] SMP
[    5.946023] Modules linked in:
[    5.949448] CPU: 5 PID: 8 Comm: rcu_sched Not tainted
4.4.110-rc1_pt_linux-4.4.110rc1 #1
[    5.958484] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
[    5.969552] task: ffff881ff2f1ab00 ti: ffff881ff2f24000 task.ti:
ffff881ff2f24000
[    5.977905] RIP: 0010:[<ffffffff810e70d2>]  [<ffffffff810e70d2>]
dyntick_save_progress_counter+0x12/0x50
[    5.988505] RSP: 0000:ffff881ff2f27dc0  EFLAGS: 00010046
[    5.994434] RAX: 0000000000000001 RBX: ffffffff81b02140 RCX: ffff883fec768000
[    6.002403] RDX: 0000000000000000 RSI: ffff881ff2f27e5f RDI: ffff88407e958140
[    6.010368] RBP: ffff881ff2f27dc0 R08: ffff881ff2f27e78 R09: 000000016110f359
[    6.018333] R10: 0000000000000b10 R11: 0000000000000000 R12: ffffffff81b02140
[    6.026297] R13: 00000000ffffffdf R14: 0000000000000021 R15: 0000000200000000
[    6.034262] FS:  0000000000000000(0000) GS:ffff881fff940000(0000)
knlGS:0000000000000000
[    6.043293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.049707] CR2: 000000000000000d CR3: 0000000001aa6000 CR4: 0000000000360670
[    6.057672] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    6.065638] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    6.073603] Stack:
[    6.075847]  ffff881ff2f27e18 ffffffff810e8fac 0000000000000202
ffff881ff2f27e60
[    6.084158]  ffff881ff2f27e5f ffffffff810e70c0 ffffffff81b02140
ffffffff81b127a0
[    6.092465]  0000000000000001 0000000000000000 0000000000000003
ffff881ff2f27eb8
[    6.100768] Call Trace:
[    6.103501]  [<ffffffff810e8fac>] force_qs_rnp+0xdc/0x150
[    6.109527]  [<ffffffff810e70c0>] ? rcu_start_gp+0x70/0x70
[    6.115654]  [<ffffffff810ea118>] rcu_gp_kthread+0x468/0x9b0
[    6.121976]  [<ffffffff810c9190>] ? prepare_to_wait_event+0xf0/0xf0
[    6.128973]  [<ffffffff810e9cb0>] ? rcu_process_callbacks+0x5f0/0x5f0
[    6.136167]  [<ffffffff810a4a25>] kthread+0xe5/0x100
[    6.141710]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60
[    6.147840]  [<ffffffff81714e8f>] ret_from_fork+0x3f/0x70
[    6.153868]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60

I tried to bisect the problem, but when I try to boot only with:
"KAISER: Kernel Address Isolation" machine hangs during boot and reboots without any panic message.

Quoted 6 lines
Quoted 6 lines
Quoted 2 lines

4.4.109 boots fine
4.9.75rc1 also boots fine.

Hm, so I'm guessing 4.15-rc6 also works?

Odd that 4.9.75-rc1 fails.

Sorry, it's been a long few days, I meant "odd that the 4.9 -rc works and the 4.4 one fails".

{sigh}

I think I need to ignore email for a while...

greg k-h

#48 lore raw
In reply to Greg Kroah-Hartman
Quoted 1 line

Hm, so I'm guessing 4.15-rc6 also works?

I have not test 4.15

Quoted 1 line

Odd that 4.9.75-rc1 fails.

4.9.75-rc1 does NOT fail, it boots fine.

config for 4.4.110rc1 panic is attached.

Thank you,
Pasha

#49 lore raw
In reply to Greg Kroah-Hartman
Quoted 52 lines · Greg Kroah-Hartman
Quoted 51 lines · Pavel Tatashin

I am getting the following panic when trying to boot 4.4.110rc1 on Intel(R) Xeon(R) CPU E5-2630:

[    5.923489] BUG: unable to handle kernel NULL pointer dereference
at 000000000000000d
[    5.932259] IP: [<ffffffff810e70d2>] dyntick_save_progress_counter+0x12/0x50
[    5.940142] PGD 0
[    5.942400] Oops: 0002 [#1] SMP
[    5.946023] Modules linked in:
[    5.949448] CPU: 5 PID: 8 Comm: rcu_sched Not tainted
4.4.110-rc1_pt_linux-4.4.110rc1 #1
[    5.958484] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
[    5.969552] task: ffff881ff2f1ab00 ti: ffff881ff2f24000 task.ti:
ffff881ff2f24000
[    5.977905] RIP: 0010:[<ffffffff810e70d2>]  [<ffffffff810e70d2>]
dyntick_save_progress_counter+0x12/0x50
[    5.988505] RSP: 0000:ffff881ff2f27dc0  EFLAGS: 00010046
[    5.994434] RAX: 0000000000000001 RBX: ffffffff81b02140 RCX: ffff883fec768000
[    6.002403] RDX: 0000000000000000 RSI: ffff881ff2f27e5f RDI: ffff88407e958140
[    6.010368] RBP: ffff881ff2f27dc0 R08: ffff881ff2f27e78 R09: 000000016110f359
[    6.018333] R10: 0000000000000b10 R11: 0000000000000000 R12: ffffffff81b02140
[    6.026297] R13: 00000000ffffffdf R14: 0000000000000021 R15: 0000000200000000
[    6.034262] FS:  0000000000000000(0000) GS:ffff881fff940000(0000)
knlGS:0000000000000000
[    6.043293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.049707] CR2: 000000000000000d CR3: 0000000001aa6000 CR4: 0000000000360670
[    6.057672] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    6.065638] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    6.073603] Stack:
[    6.075847]  ffff881ff2f27e18 ffffffff810e8fac 0000000000000202
ffff881ff2f27e60
[    6.084158]  ffff881ff2f27e5f ffffffff810e70c0 ffffffff81b02140
ffffffff81b127a0
[    6.092465]  0000000000000001 0000000000000000 0000000000000003
ffff881ff2f27eb8
[    6.100768] Call Trace:
[    6.103501]  [<ffffffff810e8fac>] force_qs_rnp+0xdc/0x150
[    6.109527]  [<ffffffff810e70c0>] ? rcu_start_gp+0x70/0x70
[    6.115654]  [<ffffffff810ea118>] rcu_gp_kthread+0x468/0x9b0
[    6.121976]  [<ffffffff810c9190>] ? prepare_to_wait_event+0xf0/0xf0
[    6.128973]  [<ffffffff810e9cb0>] ? rcu_process_callbacks+0x5f0/0x5f0
[    6.136167]  [<ffffffff810a4a25>] kthread+0xe5/0x100
[    6.141710]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60
[    6.147840]  [<ffffffff81714e8f>] ret_from_fork+0x3f/0x70
[    6.153868]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60

I tried to bisect the problem, but when I try to boot only with:
"KAISER: Kernel Address Isolation" machine hangs during boot and reboots without any panic message.

Quoted 6 lines
Quoted 2 lines

4.4.109 boots fine
4.9.75rc1 also boots fine.

Hm, so I'm guessing 4.15-rc6 also works?

Odd that 4.9.75-rc1 fails.

s/4.9.75/4.4.110/ I suppose.

Can't this be because more patches are required in 4.4 to support this patch set ? Or maybe a manual fix for a conflict that went wrong ? Just trying to guess.

Willy

author maintainer
#50 lore raw
Quoted 53 lines · Willy Tarreau
Quoted 52 lines · Greg Kroah-Hartman
Quoted 51 lines · Pavel Tatashin

I am getting the following panic when trying to boot 4.4.110rc1 on Intel(R) Xeon(R) CPU E5-2630:

[    5.923489] BUG: unable to handle kernel NULL pointer dereference
at 000000000000000d
[    5.932259] IP: [<ffffffff810e70d2>] dyntick_save_progress_counter+0x12/0x50
[    5.940142] PGD 0
[    5.942400] Oops: 0002 [#1] SMP
[    5.946023] Modules linked in:
[    5.949448] CPU: 5 PID: 8 Comm: rcu_sched Not tainted
4.4.110-rc1_pt_linux-4.4.110rc1 #1
[    5.958484] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
[    5.969552] task: ffff881ff2f1ab00 ti: ffff881ff2f24000 task.ti:
ffff881ff2f24000
[    5.977905] RIP: 0010:[<ffffffff810e70d2>]  [<ffffffff810e70d2>]
dyntick_save_progress_counter+0x12/0x50
[    5.988505] RSP: 0000:ffff881ff2f27dc0  EFLAGS: 00010046
[    5.994434] RAX: 0000000000000001 RBX: ffffffff81b02140 RCX: ffff883fec768000
[    6.002403] RDX: 0000000000000000 RSI: ffff881ff2f27e5f RDI: ffff88407e958140
[    6.010368] RBP: ffff881ff2f27dc0 R08: ffff881ff2f27e78 R09: 000000016110f359
[    6.018333] R10: 0000000000000b10 R11: 0000000000000000 R12: ffffffff81b02140
[    6.026297] R13: 00000000ffffffdf R14: 0000000000000021 R15: 0000000200000000
[    6.034262] FS:  0000000000000000(0000) GS:ffff881fff940000(0000)
knlGS:0000000000000000
[    6.043293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.049707] CR2: 000000000000000d CR3: 0000000001aa6000 CR4: 0000000000360670
[    6.057672] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    6.065638] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    6.073603] Stack:
[    6.075847]  ffff881ff2f27e18 ffffffff810e8fac 0000000000000202
ffff881ff2f27e60
[    6.084158]  ffff881ff2f27e5f ffffffff810e70c0 ffffffff81b02140
ffffffff81b127a0
[    6.092465]  0000000000000001 0000000000000000 0000000000000003
ffff881ff2f27eb8
[    6.100768] Call Trace:
[    6.103501]  [<ffffffff810e8fac>] force_qs_rnp+0xdc/0x150
[    6.109527]  [<ffffffff810e70c0>] ? rcu_start_gp+0x70/0x70
[    6.115654]  [<ffffffff810ea118>] rcu_gp_kthread+0x468/0x9b0
[    6.121976]  [<ffffffff810c9190>] ? prepare_to_wait_event+0xf0/0xf0
[    6.128973]  [<ffffffff810e9cb0>] ? rcu_process_callbacks+0x5f0/0x5f0
[    6.136167]  [<ffffffff810a4a25>] kthread+0xe5/0x100
[    6.141710]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60
[    6.147840]  [<ffffffff81714e8f>] ret_from_fork+0x3f/0x70
[    6.153868]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60

I tried to bisect the problem, but when I try to boot only with:
"KAISER: Kernel Address Isolation" machine hangs during boot and reboots without any panic message.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

4.4.109 boots fine
4.9.75rc1 also boots fine.

Hm, so I'm guessing 4.15-rc6 also works?

Odd that 4.9.75-rc1 fails.

s/4.9.75/4.4.110/ I suppose.

Yes, mistake on my side.

Quoted 3 lines

Can't this be because more patches are required in 4.4 to support this patch set ? Or maybe a manual fix for a conflict that went wrong ? Just trying to guess.

Odd thing is, the 4.9 series started from the 4.4 code for most of the patches, so I would expect that one to fail...

greg k-h

author maintainer
#51 lore raw
Quoted 63 lines · Greg Kroah-Hartman
Quoted 53 lines · Willy Tarreau
Quoted 52 lines · Greg Kroah-Hartman
Quoted 51 lines · Pavel Tatashin

I am getting the following panic when trying to boot 4.4.110rc1 on Intel(R) Xeon(R) CPU E5-2630:

[    5.923489] BUG: unable to handle kernel NULL pointer dereference
at 000000000000000d
[    5.932259] IP: [<ffffffff810e70d2>] dyntick_save_progress_counter+0x12/0x50
[    5.940142] PGD 0
[    5.942400] Oops: 0002 [#1] SMP
[    5.946023] Modules linked in:
[    5.949448] CPU: 5 PID: 8 Comm: rcu_sched Not tainted
4.4.110-rc1_pt_linux-4.4.110rc1 #1
[    5.958484] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
[    5.969552] task: ffff881ff2f1ab00 ti: ffff881ff2f24000 task.ti:
ffff881ff2f24000
[    5.977905] RIP: 0010:[<ffffffff810e70d2>]  [<ffffffff810e70d2>]
dyntick_save_progress_counter+0x12/0x50
[    5.988505] RSP: 0000:ffff881ff2f27dc0  EFLAGS: 00010046
[    5.994434] RAX: 0000000000000001 RBX: ffffffff81b02140 RCX: ffff883fec768000
[    6.002403] RDX: 0000000000000000 RSI: ffff881ff2f27e5f RDI: ffff88407e958140
[    6.010368] RBP: ffff881ff2f27dc0 R08: ffff881ff2f27e78 R09: 000000016110f359
[    6.018333] R10: 0000000000000b10 R11: 0000000000000000 R12: ffffffff81b02140
[    6.026297] R13: 00000000ffffffdf R14: 0000000000000021 R15: 0000000200000000
[    6.034262] FS:  0000000000000000(0000) GS:ffff881fff940000(0000)
knlGS:0000000000000000
[    6.043293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.049707] CR2: 000000000000000d CR3: 0000000001aa6000 CR4: 0000000000360670
[    6.057672] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    6.065638] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    6.073603] Stack:
[    6.075847]  ffff881ff2f27e18 ffffffff810e8fac 0000000000000202
ffff881ff2f27e60
[    6.084158]  ffff881ff2f27e5f ffffffff810e70c0 ffffffff81b02140
ffffffff81b127a0
[    6.092465]  0000000000000001 0000000000000000 0000000000000003
ffff881ff2f27eb8
[    6.100768] Call Trace:
[    6.103501]  [<ffffffff810e8fac>] force_qs_rnp+0xdc/0x150
[    6.109527]  [<ffffffff810e70c0>] ? rcu_start_gp+0x70/0x70
[    6.115654]  [<ffffffff810ea118>] rcu_gp_kthread+0x468/0x9b0
[    6.121976]  [<ffffffff810c9190>] ? prepare_to_wait_event+0xf0/0xf0
[    6.128973]  [<ffffffff810e9cb0>] ? rcu_process_callbacks+0x5f0/0x5f0
[    6.136167]  [<ffffffff810a4a25>] kthread+0xe5/0x100
[    6.141710]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60
[    6.147840]  [<ffffffff81714e8f>] ret_from_fork+0x3f/0x70
[    6.153868]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60

I tried to bisect the problem, but when I try to boot only with:
"KAISER: Kernel Address Isolation" machine hangs during boot and reboots without any panic message.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

4.4.109 boots fine
4.9.75rc1 also boots fine.

Hm, so I'm guessing 4.15-rc6 also works?

Odd that 4.9.75-rc1 fails.

s/4.9.75/4.4.110/ I suppose.

Quoted 8 lines

Yes, mistake on my side.

Quoted 3 lines

Can't this be because more patches are required in 4.4 to support this patch set ? Or maybe a manual fix for a conflict that went wrong ? Just trying to guess.

Odd thing is, the 4.9 series started from the 4.4 code for most of the patches, so I would expect that one to fail...

Also, the 4.4 patches were supposed to have been better tested, I need to go dig and see what I messed up here...

greg k-h

author maintainer
#52 lore raw
Quoted 70 lines · Greg Kroah-Hartman
Quoted 69 lines · Greg Kroah-Hartman
Quoted 53 lines · Willy Tarreau
Quoted 52 lines · Greg Kroah-Hartman
Quoted 51 lines · Pavel Tatashin

I am getting the following panic when trying to boot 4.4.110rc1 on Intel(R) Xeon(R) CPU E5-2630:

[    5.923489] BUG: unable to handle kernel NULL pointer dereference
at 000000000000000d
[    5.932259] IP: [<ffffffff810e70d2>] dyntick_save_progress_counter+0x12/0x50
[    5.940142] PGD 0
[    5.942400] Oops: 0002 [#1] SMP
[    5.946023] Modules linked in:
[    5.949448] CPU: 5 PID: 8 Comm: rcu_sched Not tainted
4.4.110-rc1_pt_linux-4.4.110rc1 #1
[    5.958484] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
[    5.969552] task: ffff881ff2f1ab00 ti: ffff881ff2f24000 task.ti:
ffff881ff2f24000
[    5.977905] RIP: 0010:[<ffffffff810e70d2>]  [<ffffffff810e70d2>]
dyntick_save_progress_counter+0x12/0x50
[    5.988505] RSP: 0000:ffff881ff2f27dc0  EFLAGS: 00010046
[    5.994434] RAX: 0000000000000001 RBX: ffffffff81b02140 RCX: ffff883fec768000
[    6.002403] RDX: 0000000000000000 RSI: ffff881ff2f27e5f RDI: ffff88407e958140
[    6.010368] RBP: ffff881ff2f27dc0 R08: ffff881ff2f27e78 R09: 000000016110f359
[    6.018333] R10: 0000000000000b10 R11: 0000000000000000 R12: ffffffff81b02140
[    6.026297] R13: 00000000ffffffdf R14: 0000000000000021 R15: 0000000200000000
[    6.034262] FS:  0000000000000000(0000) GS:ffff881fff940000(0000)
knlGS:0000000000000000
[    6.043293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.049707] CR2: 000000000000000d CR3: 0000000001aa6000 CR4: 0000000000360670
[    6.057672] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    6.065638] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    6.073603] Stack:
[    6.075847]  ffff881ff2f27e18 ffffffff810e8fac 0000000000000202
ffff881ff2f27e60
[    6.084158]  ffff881ff2f27e5f ffffffff810e70c0 ffffffff81b02140
ffffffff81b127a0
[    6.092465]  0000000000000001 0000000000000000 0000000000000003
ffff881ff2f27eb8
[    6.100768] Call Trace:
[    6.103501]  [<ffffffff810e8fac>] force_qs_rnp+0xdc/0x150
[    6.109527]  [<ffffffff810e70c0>] ? rcu_start_gp+0x70/0x70
[    6.115654]  [<ffffffff810ea118>] rcu_gp_kthread+0x468/0x9b0
[    6.121976]  [<ffffffff810c9190>] ? prepare_to_wait_event+0xf0/0xf0
[    6.128973]  [<ffffffff810e9cb0>] ? rcu_process_callbacks+0x5f0/0x5f0
[    6.136167]  [<ffffffff810a4a25>] kthread+0xe5/0x100
[    6.141710]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60
[    6.147840]  [<ffffffff81714e8f>] ret_from_fork+0x3f/0x70
[    6.153868]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60

I tried to bisect the problem, but when I try to boot only with:
"KAISER: Kernel Address Isolation" machine hangs during boot and reboots without any panic message.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

4.4.109 boots fine
4.9.75rc1 also boots fine.

Hm, so I'm guessing 4.15-rc6 also works?

Odd that 4.9.75-rc1 fails.

s/4.9.75/4.4.110/ I suppose.

Yes, mistake on my side.

Quoted 3 lines

Can't this be because more patches are required in 4.4 to support this patch set ? Or maybe a manual fix for a conflict that went wrong ? Just trying to guess.

Quoted 5 lines
Quoted 2 lines

Odd thing is, the 4.9 series started from the 4.4 code for most of the patches, so I would expect that one to fail...

Also, the 4.4 patches were supposed to have been better tested, I need to go dig and see what I messed up here...

Nope, it matches up with what is in SLES12 exactly, I must be missing something else here as a prerequisite...

#53 lore raw
Quoted 71 lines · Greg Kroah-Hartman
Quoted 70 lines · Greg Kroah-Hartman
Quoted 69 lines · Greg Kroah-Hartman
Quoted 53 lines · Willy Tarreau
Quoted 52 lines · Greg Kroah-Hartman
Quoted 51 lines · Pavel Tatashin

I am getting the following panic when trying to boot 4.4.110rc1 on Intel(R) Xeon(R) CPU E5-2630:

[    5.923489] BUG: unable to handle kernel NULL pointer dereference
at 000000000000000d
[    5.932259] IP: [<ffffffff810e70d2>] dyntick_save_progress_counter+0x12/0x50
[    5.940142] PGD 0
[    5.942400] Oops: 0002 [#1] SMP
[    5.946023] Modules linked in:
[    5.949448] CPU: 5 PID: 8 Comm: rcu_sched Not tainted
4.4.110-rc1_pt_linux-4.4.110rc1 #1
[    5.958484] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
[    5.969552] task: ffff881ff2f1ab00 ti: ffff881ff2f24000 task.ti:
ffff881ff2f24000
[    5.977905] RIP: 0010:[<ffffffff810e70d2>]  [<ffffffff810e70d2>]
dyntick_save_progress_counter+0x12/0x50
[    5.988505] RSP: 0000:ffff881ff2f27dc0  EFLAGS: 00010046
[    5.994434] RAX: 0000000000000001 RBX: ffffffff81b02140 RCX: ffff883fec768000
[    6.002403] RDX: 0000000000000000 RSI: ffff881ff2f27e5f RDI: ffff88407e958140
[    6.010368] RBP: ffff881ff2f27dc0 R08: ffff881ff2f27e78 R09: 000000016110f359
[    6.018333] R10: 0000000000000b10 R11: 0000000000000000 R12: ffffffff81b02140
[    6.026297] R13: 00000000ffffffdf R14: 0000000000000021 R15: 0000000200000000
[    6.034262] FS:  0000000000000000(0000) GS:ffff881fff940000(0000)
knlGS:0000000000000000
[    6.043293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.049707] CR2: 000000000000000d CR3: 0000000001aa6000 CR4: 0000000000360670
[    6.057672] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    6.065638] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    6.073603] Stack:
[    6.075847]  ffff881ff2f27e18 ffffffff810e8fac 0000000000000202
ffff881ff2f27e60
[    6.084158]  ffff881ff2f27e5f ffffffff810e70c0 ffffffff81b02140
ffffffff81b127a0
[    6.092465]  0000000000000001 0000000000000000 0000000000000003
ffff881ff2f27eb8
[    6.100768] Call Trace:
[    6.103501]  [<ffffffff810e8fac>] force_qs_rnp+0xdc/0x150
[    6.109527]  [<ffffffff810e70c0>] ? rcu_start_gp+0x70/0x70
[    6.115654]  [<ffffffff810ea118>] rcu_gp_kthread+0x468/0x9b0
[    6.121976]  [<ffffffff810c9190>] ? prepare_to_wait_event+0xf0/0xf0
[    6.128973]  [<ffffffff810e9cb0>] ? rcu_process_callbacks+0x5f0/0x5f0
[    6.136167]  [<ffffffff810a4a25>] kthread+0xe5/0x100
[    6.141710]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60
[    6.147840]  [<ffffffff81714e8f>] ret_from_fork+0x3f/0x70
[    6.153868]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60

I tried to bisect the problem, but when I try to boot only with:
"KAISER: Kernel Address Isolation" machine hangs during boot and reboots without any panic message.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

4.4.109 boots fine
4.9.75rc1 also boots fine.

Hm, so I'm guessing 4.15-rc6 also works?

Odd that 4.9.75-rc1 fails.

s/4.9.75/4.4.110/ I suppose.

Yes, mistake on my side.

Quoted 3 lines

Can't this be because more patches are required in 4.4 to support this patch set ? Or maybe a manual fix for a conflict that went wrong ? Just trying to guess.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

Odd thing is, the 4.9 series started from the 4.4 code for most of the patches, so I would expect that one to fail...

Also, the 4.4 patches were supposed to have been better tested, I need to go dig and see what I messed up here...

Nope, it matches up with what is in SLES12 exactly, I must be missing something else here as a prerequisite...

FWIW, v4.4.110-rc1 boots fine when merged into chromeos-4.4, on i7-7Y75.

Guenter

author maintainer
#54 lore raw
Quoted 75 lines · Guenter Roeck
Quoted 74 lines · Greg Kroah-Hartman
Quoted 73 lines · Greg Kroah-Hartman
Quoted 71 lines · Greg Kroah-Hartman
Quoted 53 lines · Willy Tarreau
Quoted 52 lines · Greg Kroah-Hartman
Quoted 51 lines · Pavel Tatashin

I am getting the following panic when trying to boot 4.4.110rc1 on Intel(R) Xeon(R) CPU E5-2630:

[    5.923489] BUG: unable to handle kernel NULL pointer dereference
at 000000000000000d
[    5.932259] IP: [<ffffffff810e70d2>] dyntick_save_progress_counter+0x12/0x50
[    5.940142] PGD 0
[    5.942400] Oops: 0002 [#1] SMP
[    5.946023] Modules linked in:
[    5.949448] CPU: 5 PID: 8 Comm: rcu_sched Not tainted
4.4.110-rc1_pt_linux-4.4.110rc1 #1
[    5.958484] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
[    5.969552] task: ffff881ff2f1ab00 ti: ffff881ff2f24000 task.ti:
ffff881ff2f24000
[    5.977905] RIP: 0010:[<ffffffff810e70d2>]  [<ffffffff810e70d2>]
dyntick_save_progress_counter+0x12/0x50
[    5.988505] RSP: 0000:ffff881ff2f27dc0  EFLAGS: 00010046
[    5.994434] RAX: 0000000000000001 RBX: ffffffff81b02140 RCX: ffff883fec768000
[    6.002403] RDX: 0000000000000000 RSI: ffff881ff2f27e5f RDI: ffff88407e958140
[    6.010368] RBP: ffff881ff2f27dc0 R08: ffff881ff2f27e78 R09: 000000016110f359
[    6.018333] R10: 0000000000000b10 R11: 0000000000000000 R12: ffffffff81b02140
[    6.026297] R13: 00000000ffffffdf R14: 0000000000000021 R15: 0000000200000000
[    6.034262] FS:  0000000000000000(0000) GS:ffff881fff940000(0000)
knlGS:0000000000000000
[    6.043293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.049707] CR2: 000000000000000d CR3: 0000000001aa6000 CR4: 0000000000360670
[    6.057672] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    6.065638] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    6.073603] Stack:
[    6.075847]  ffff881ff2f27e18 ffffffff810e8fac 0000000000000202
ffff881ff2f27e60
[    6.084158]  ffff881ff2f27e5f ffffffff810e70c0 ffffffff81b02140
ffffffff81b127a0
[    6.092465]  0000000000000001 0000000000000000 0000000000000003
ffff881ff2f27eb8
[    6.100768] Call Trace:
[    6.103501]  [<ffffffff810e8fac>] force_qs_rnp+0xdc/0x150
[    6.109527]  [<ffffffff810e70c0>] ? rcu_start_gp+0x70/0x70
[    6.115654]  [<ffffffff810ea118>] rcu_gp_kthread+0x468/0x9b0
[    6.121976]  [<ffffffff810c9190>] ? prepare_to_wait_event+0xf0/0xf0
[    6.128973]  [<ffffffff810e9cb0>] ? rcu_process_callbacks+0x5f0/0x5f0
[    6.136167]  [<ffffffff810a4a25>] kthread+0xe5/0x100
[    6.141710]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60
[    6.147840]  [<ffffffff81714e8f>] ret_from_fork+0x3f/0x70
[    6.153868]  [<ffffffff810a4940>] ? kthread_park+0x60/0x60

I tried to bisect the problem, but when I try to boot only with:
"KAISER: Kernel Address Isolation" machine hangs during boot and reboots without any panic message.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

4.4.109 boots fine
4.9.75rc1 also boots fine.

Hm, so I'm guessing 4.15-rc6 also works?

Odd that 4.9.75-rc1 fails.

s/4.9.75/4.4.110/ I suppose.

Yes, mistake on my side.

Quoted 3 lines

Can't this be because more patches are required in 4.4 to support this patch set ? Or maybe a manual fix for a conflict that went wrong ? Just trying to guess.

Odd thing is, the 4.9 series started from the 4.4 code for most of the patches, so I would expect that one to fail...

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

Also, the 4.4 patches were supposed to have been better tested, I need to go dig and see what I messed up here...

Nope, it matches up with what is in SLES12 exactly, I must be missing something else here as a prerequisite...

FWIW, v4.4.110-rc1 boots fine when merged into chromeos-4.4, on i7-7Y75.

That's good to know, hopefully 4.4.110-final also still works for you :)

#55 lore raw
Quoted 5 lines · Greg Kroah-Hartman
Quoted 2 lines · Guenter Roeck

FWIW, v4.4.110-rc1 boots fine when merged into chromeos-4.4, on i7-7Y75.

That's good to know, hopefully 4.4.110-final also still works for you :)

It seems to be working. One patch to add for v4.4.111:

063fb3e56f6d ("x86/kasan: Write protect kasan zero shadow")

It is needed to be able to run KASAN enabled images in KVM.

Guenter

author maintainer
#56 lore raw
Quoted 5 lines · Guenter Roeck
Quoted 4 lines · Greg Kroah-Hartman
Quoted 2 lines · Guenter Roeck

FWIW, v4.4.110-rc1 boots fine when merged into chromeos-4.4, on i7-7Y75.

Quoted 7 lines
Quoted 1 line

That's good to know, hopefully 4.4.110-final also still works for you :)

It seems to be working. One patch to add for v4.4.111:

063fb3e56f6d ("x86/kasan: Write protect kasan zero shadow")

It is needed to be able to run KASAN enabled images in KVM.

Ugh, thanks for that, it also looks like SLES also is missing that one too.

thanks,

greg k-h

#57 lore raw
In reply to Greg Kroah-Hartman
Quoted 6 lines · Greg Kroah-Hartman
Quoted 3 lines

Can't this be because more patches are required in 4.4 to support this patch set ? Or maybe a manual fix for a conflict that went wrong ? Just trying to guess.

Odd thing is, the 4.9 series started from the 4.4 code for most of the patches, so I would expect that one to fail...

I see. Then maybe a missing patch somewhere in 4.4 compared to 4.9 :-/ I have no idea what to look for however.

Willy

#58 lore raw
In reply to Pavel Tatashin
Quoted 5 lines · Pavel Tatashin

I am getting the following panic when trying to boot 4.4.110rc1 on Intel(R) Xeon(R) CPU E5-2630:

[    5.923489] BUG: unable to handle kernel NULL pointer dereference at 000000000000000d
[    5.932259] IP: [<ffffffff810e70d2>] dyntick_save_progress_counter+0x12/0x50

Hmm. You don't have the "Code:" line in this oops anywhere, do you?

Quoted 10 lines
[    5.977905] RIP: dyntick_save_progress_counter+0x12/0x50
[    5.988505] RSP: 0000:ffff881ff2f27dc0  EFLAGS: 00010046
[    5.994434] RAX: 0000000000000001 RBX: ffffffff81b02140 RCX: ffff883fec768000
[    6.002403] RDX: 0000000000000000 RSI: ffff881ff2f27e5f RDI: ffff88407e958140
[    6.010368] RBP: ffff881ff2f27dc0 R08: ffff881ff2f27e78 R09: 000000016110f359
[    6.018333] R10: 0000000000000b10 R11: 0000000000000000 R12: ffffffff81b02140
[    6.026297] R13: 00000000ffffffdf R14: 0000000000000021 R15: 0000000200000000
[    6.034262] FS:  0000000000000000(0000) GS:ffff881fff940000(0000) knlGS:0000000000000000
[    6.043293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.049707] CR2: 000000000000000d CR3: 0000000001aa6000 CR4: 0000000000360670
Quoted 8 lines
[    6.057672] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    6.065638] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    6.073603] Stack:
[    6.075847]  ffff881ff2f27e18 ffffffff810e8fac 0000000000000202 ffff881ff2f27e60
[    6.084158]  ffff881ff2f27e5f ffffffff810e70c0 ffffffff81b02140 ffffffff81b127a0
[    6.092465]  0000000000000001 0000000000000000 0000000000000003 ffff881ff2f27eb8
[    6.100768] Call Trace:
[    6.103501]  [<ffffffff810e8fac>] force_qs_rnp+0xdc/0x150

The oops looks like it *might* be this:

        lock xadd %edx,0xc(%rax)

which is from the

        int snap = atomic_add_return(0, &rdtp->dynticks);

in rcu_dynticks_snap() because %rax is 1 and that would give you the invalid page fault and the right faulting address.

But that would be complete rcu data structure corruption (that rdtp pointer comes from

        per_cpu_ptr(rsp->rda, cpu)

in force_qs_rnp(), afaik.

The PTI patches obviously change percpu stuff, but this looks like an odd place for that to manifest.

Linus

#59 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

For v4.4.109-38-g99abd6c:

Build results:

	total: 145 pass: 145 fail: 0
Qemu test results:
	total: 118 pass: 118 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

#60 lore raw
In reply to Greg Kroah-Hartman

When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a segfault and the kernel panics (attempted to kill init). The VM host is a Haswell system.

The same kernel binary boots fine on a (other) Haswell system.

I tried:

4.4.110-rc1     broken
4.4.109         ok
4.9.75-rc1      ok

All systems are OpenSuSE 42.3 64bit.

qemu is started only with:
qemu-system-x86_64 -m 2048 -enable-kvm -drive file=tvsuse,format=raw,if=none,id=virtdisk0 -device virtio-blk-pci,scsi=off,drive=virtdisk0

Am I the only one who sees this? Has anyone booted that kernel on qemu?

Confused,

Thomas

author maintainer
#61 lore raw
Quoted 5 lines · Thomas Voegtle

When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a segfault and the kernel panics (attempted to kill init). The VM host is a Haswell system.

Quoted 7 lines

The same kernel binary boots fine on a (other) Haswell system.

I tried:

4.4.110-rc1     broken
4.4.109         ok
4.9.75-rc1      ok

Does 4.15-rc6 also work ok?

Quoted 8 lines

All systems are OpenSuSE 42.3 64bit.

qemu is started only with:
qemu-system-x86_64 -m 2048 -enable-kvm -drive file=tvsuse,format=raw,if=none,id=virtdisk0 -device virtio-blk-pci,scsi=off,drive=virtdisk0

Am I the only one who sees this? Has anyone booted that kernel on qemu?

Any chance we can see the panic?

There's another error report of this same type of thing on this thread, did you see that?

thanks,

greg k-h

#62 lore raw
Quoted 8 lines · Greg Kroah-Hartman
Quoted 7 lines · Thomas Voegtle

When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a segfault and the kernel panics (attempted to kill init). The VM host is a Haswell system.

The same kernel binary boots fine on a (other) Haswell system.

Quoted 7 lines
Quoted 5 lines

I tried:

4.4.110-rc1     broken
4.4.109         ok
4.9.75-rc1      ok

Does 4.15-rc6 also work ok?

Yes. Slightly different kernel config, but it boots.

Quoted 10 lines
Quoted 8 lines

All systems are OpenSuSE 42.3 64bit.

qemu is started only with:
qemu-system-x86_64 -m 2048 -enable-kvm -drive file=tvsuse,format=raw,if=none,id=virtdisk0 -device virtio-blk-pci,scsi=off,drive=virtdisk0

Am I the only one who sees this? Has anyone booted that kernel on qemu?

Any chance we can see the panic?

Attached a screenshot.
Is that useful? Are there some debug options I can add?

#63 lore raw
Quoted 3 lines · Thomas Voegtle

Attached a screenshot.
Is that useful? Are there some debug options I can add?

Not much of an oops, because the SIGSEGV happens in user space. The only reason you get any kernel stack printout at all is because 'init' dying will make the kernel print that out.

The segfault address for init looks like the fixmap area to me (first byte in the last page of the fixmap?). "Error 5" means that it's a user-space read that got a protection fault. So it's not a LDT of GDT update or anything like that, it's a normal access from user space (or a qemu emulation bug, but that sounds unlikely).

Is that the vsyscall page?

Adding Luto to the participants. I think he noticed one of the vsyscall patches missing earlier in the 4.9 series. Maybe the 4.4 series had something similar..

Linus

#64 lore raw
Quoted 18 lines · Linus Torvalds
Quoted 5 lines · Thomas Voegtle

Attached a screenshot.
Is that useful? Are there some debug options I can add?

Not much of an oops, because the SIGSEGV happens in user space. The only reason you get any kernel stack printout at all is because 'init' dying will make the kernel print that out.

The segfault address for init looks like the fixmap area to me (first byte in the last page of the fixmap?). "Error 5" means that it's a user-space read that got a protection fault. So it's not a LDT of GDT update or anything like that, it's a normal access from user space (or a qemu emulation bug, but that sounds unlikely).

Quoted 6 lines

Is that the vsyscall page?

Adding Luto to the participants. I think he noticed one of the vsyscall patches missing earlier in the 4.9 series. Maybe the 4.4 series had something similar..

That's almost certainly it.

I'll try to find some time today or tomorrow to add a proper selftest.

Quoted 1 line

Linus

#65 lore raw
Quoted 18 lines · Andy Lutomirski
Quoted 18 lines · Linus Torvalds
Quoted 5 lines · Thomas Voegtle

Attached a screenshot.
Is that useful? Are there some debug options I can add?

Not much of an oops, because the SIGSEGV happens in user space. The only reason you get any kernel stack printout at all is because 'init' dying will make the kernel print that out.

The segfault address for init looks like the fixmap area to me (first byte in the last page of the fixmap?). "Error 5" means that it's a user-space read that got a protection fault. So it's not a LDT of GDT update or anything like that, it's a normal access from user space (or a qemu emulation bug, but that sounds unlikely).

Quoted 8 lines
Quoted 6 lines

Is that the vsyscall page?

Adding Luto to the participants. I think he noticed one of the vsyscall patches missing earlier in the 4.9 series. Maybe the 4.4 series had something similar..

That's almost certainly it.

I'm hopeless on the FIXMAP arithmetic, but I'm pretty sure that ffffffffff5ff000 is either VSYSCALL page or PVCLOCK page (I think it was VVAR page when init segfaulted on it in my 3.2).

I'll forward Borislav's suggested 4.4 VSYSCALL patch from the kaiser backports ml to Thomas, to see if that sorts his crash (forwarding in the hope that gmail doesn't mess up the patch).

Seems odd that 4.4 should be broken but 4.9 not broken here, I'd expect them to be equally known broken with respect to VSYSCALL; but perhaps it's a matter of userspace trying different fallbacks according to what kernel supports, and only hitting this on 4.4.

Hugh

Quoted 4 lines

I'll try to find some time today Thomnor tomorrow to add a proper selftest.

Quoted 1 line

Linus

#66 lore raw
Quoted 30 lines · Hugh Dickins
Quoted 27 lines · Andy Lutomirski
Quoted 24 lines
Quoted 7 lines · Linus Torvalds

On Thu, Jan 4, 2018 at 12:16 PM, Thomas Voegtle <[email protected]> wrote:

Attached a screenshot.
Is that useful? Are there some debug options I can add?

Not much of an oops, because the SIGSEGV happens in user space. The only reason you get any kernel stack printout at all is because 'init' dying will make the kernel print that out.

The segfault address for init looks like the fixmap area to me (first byte in the last page of the fixmap?). "Error 5" means that it's a user-space read that got a protection fault. So it's not a LDT of GDT update or anything like that, it's a normal access from user space (or a qemu emulation bug, but that sounds unlikely).

Is that the vsyscall page?

Adding Luto to the participants. I think he noticed one of the vsyscall patches missing earlier in the 4.9 series. Maybe the 4.4 series had something similar..

Quoted 5 lines
Quoted 1 line

That's almost certainly it.

I'm hopeless on the FIXMAP arithmetic, but I'm pretty sure that ffffffffff5ff000 is either VSYSCALL page or PVCLOCK page (I think it was VVAR page when init segfaulted on it in my 3.2).

Nah, that's one page below VSYSCALL. Vvar is 0x7fff...

I don't have the actual screenshot, I think.

Quoted 9 lines

I'll forward Borislav's suggested 4.4 VSYSCALL patch from the kaiser backports ml to Thomas, to see if that sorts his crash (forwarding in the hope that gmail doesn't mess up the patch).

Seems odd that 4.4 should be broken but 4.9 not broken here, I'd expect them to be equally known broken with respect to VSYSCALL; but perhaps it's a matter of userspace trying different fallbacks according to what kernel supports, and only hitting this on 4.4.

I don't think any current userspace is that dumb. But Go was still using vsyscall fairly recently.

I may be able to look for real tonight.

Quoted 7 lines

Hugh

Quoted 4 lines

I'll try to find some time today Thomnor tomorrow to add a proper selftest.

Quoted 1 line

Linus

#67 lore raw
In reply to Hugh Dickins

I tried cherry picking
435086b36f62 x86/vsyscall/64: Explicitly set _PAGE_USER in the
pagetable hierarchy

on top of 4.4.110-rc1, (needed to resolve a small 5level table to 4level page table conflict). Unfortunately, this does not solve the panic/hanging problem I reported. For some reason I do not see the panic message anymore. Machine hangs here:

[    5.023052] zswap: loaded using pool lzo/zbud
[    5.023063] page_owner is disabled
[    5.026492] Key type trusted registered
[    5.029325] Key type encrypted registered
[    5.029330] ima: No TPM chip found, activating TPM-bypass!
[    5.029365] evm: HMAC attrs: 0x1
[    5.034696] rtc_cmos 00:00: setting system clock to 2018-01-04
21:20:34 UTC (1515100834)
[    5.216862] Freeing unused kernel memory: 1856K

<hang>

And reboots after about half a minute.

Thank you,
Pavel

#68 lore raw
Quoted 18 lines · Pavel Tatashin

I tried cherry picking
435086b36f62 x86/vsyscall/64: Explicitly set _PAGE_USER in the
pagetable hierarchy

on top of 4.4.110-rc1, (needed to resolve a small 5level table to 4level page table conflict). Unfortunately, this does not solve the panic/hanging problem I reported. For some reason I do not see the panic message anymore. Machine hangs here:

[    5.023052] zswap: loaded using pool lzo/zbud
[    5.023063] page_owner is disabled
[    5.026492] Key type trusted registered
[    5.029325] Key type encrypted registered
[    5.029330] ima: No TPM chip found, activating TPM-bypass!
[    5.029365] evm: HMAC attrs: 0x1
[    5.034696] rtc_cmos 00:00: setting system clock to 2018-01-04
21:20:34 UTC (1515100834)
[    5.216862] Freeing unused kernel memory: 1856K
Quoted 3 lines

<hang>

And reboots after about half a minute.

Thanks for trying, but yes, I wouldn't expect a straight cherry-pick of that to work in the context of 4.4.110: it needs to be cherry-picked "in principle". Which Borislav has done, and I'll forward you his (not yet reviewed) patch too, but frankly I've much less hope that it will help your crash than Thomas's.

So please revert that cherry-pick; and if Borislav's patch doesn't help, if you can send us a "Code:" line from the crash, that may still give us more to go on.

As Linus remarked earlier, "The PTI patches obviously change percpu stuff, but this looks like an odd place for that to manifest".
Exactly: segfault and panic when starting init is a "normal" symptom when we get something wrong with Kaiser/PTI, but a kthread crashing in dyntick_save_progress_counter is something new to me.

Hugh

#69 lore raw
[    6.159992] Code: 89 83 78 06 01 00 b8 01 00 00 00 5b 41 5c 41 5d

5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 31 d2 48 8b 87 c8 00 00 00 48 89 e5 <f0> 0f c1 50 0c 89 97 d0 00 00 00 83 e2 01 b8 01 00 00 00 74 1d

Also, attached is the full console output.

Thank you,
Pavel

Quoted 41 lines · Hugh Dickins
Quoted 18 lines · Pavel Tatashin

I tried cherry picking
435086b36f62 x86/vsyscall/64: Explicitly set _PAGE_USER in the
pagetable hierarchy

on top of 4.4.110-rc1, (needed to resolve a small 5level table to 4level page table conflict). Unfortunately, this does not solve the panic/hanging problem I reported. For some reason I do not see the panic message anymore. Machine hangs here:

[    5.023052] zswap: loaded using pool lzo/zbud
[    5.023063] page_owner is disabled
[    5.026492] Key type trusted registered
[    5.029325] Key type encrypted registered
[    5.029330] ima: No TPM chip found, activating TPM-bypass!
[    5.029365] evm: HMAC attrs: 0x1
[    5.034696] rtc_cmos 00:00: setting system clock to 2018-01-04
21:20:34 UTC (1515100834)
[    5.216862] Freeing unused kernel memory: 1856K
Quoted 3 lines

<hang>

And reboots after about half a minute.

Thanks for trying, but yes, I wouldn't expect a straight cherry-pick of that to work in the context of 4.4.110: it needs to be cherry-picked "in principle". Which Borislav has done, and I'll forward you his (not yet reviewed) patch too, but frankly I've much less hope that it will help your crash than Thomas's.

So please revert that cherry-pick; and if Borislav's patch doesn't help, if you can send us a "Code:" line from the crash, that may still give us more to go on.

As Linus remarked earlier, "The PTI patches obviously change percpu stuff, but this looks like an odd place for that to manifest".
Exactly: segfault and panic when starting init is a "normal" symptom when we get something wrong with Kaiser/PTI, but a kthread crashing in dyntick_save_progress_counter is something new to me.

Hugh

#70 lore raw
Quoted 4 lines · Pavel Tatashin
[    6.159992] Code: 89 83 78 06 01 00 b8 01 00 00 00 5b 41 5c 41 5d

5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 31 d2 48 8b 87 c8 00 00 00 48 89 e5 <f0> 0f c1 50 0c 89 97 d0 00 00 00 83 e2 01 b8 01 00 00 00 74 1d

Yeah, it's the "lock xadd" as suspected:

   0:   0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
   5:   55                      push   %rbp
   6:   31 d2                   xor    %edx,%edx
   8:   48 8b 87 c8 00 00 00    mov    0xc8(%rdi),%rax
   f:   48 89 e5                mov    %rsp,%rbp
  12:*  f0 0f c1 50 0c          lock xadd %edx,0xc(%rax)
 <-- trapping instruction
  17:   89 97 d0 00 00 00       mov    %edx,0xd0(%rdi)
  1d:   83 e2 01                and    $0x1,%edx
  20:   b8 01 00 00 00          mov    $0x1,%eax
  25:   74 1d                   je     0x44

(that first "nop" is a 5-byte nop that is used for the function tracing placeholder).

And %rax contains garbage (the value "1", rather than a valid kernel pointer).

Sadly, I have no idea about how that garbage came about.

Linus

author maintainer
#71 lore raw
In reply to Pavel Tatashin
Quoted 6 lines · Pavel Tatashin
[    6.159992] Code: 89 83 78 06 01 00 b8 01 00 00 00 5b 41 5c 41 5d

5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 31 d2 48 8b 87 c8 00 00 00 48 89 e5 <f0> 0f c1 50 0c 89 97 d0 00 00 00 83 e2 01 b8 01 00 00 00 74 1d

Also, attached is the full console output.

Ick, like the others, I have no idea what happened here.

But, can you tgest 4.4.110 now? It has 4 more patches on top of what you were testing with here for 4.4.110-rc1, that hopefully should resolve this type of issue.

And if not, it would be good for us to know :)

thanks so much for testing,

greg k-h

#72 lore raw

Hi Greg,

Just tested on my machine:

[    0.000000] Initializing cgroup subsys cpuset 
[    0.000000] Initializing cgroup subsys cpu 
[    0.000000] Initializing cgroup subsys cpuacct 
[    0.000000] Linux version 4.4.110_pt_linux-v4.4.110 (ptatashi@ca-ostest441) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) ) #1 SMP Fri Jan 5 07:22:34 PST 2018
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.4.110_pt_linux-v4.4.110 root=UUID=fe908085-0117-442b-a57c-ce651cc95b38 ro crashkernel=auto console=ttyS0,115200 LANG=en_US.UTF-8
[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256 
[    0.000000] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers' 
[    0.000000] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers' 
[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. 

<cut>

[    3.457106] hub 1-0:1.0: USB hub found 
[    3.461298] hub 1-0:1.0: 2 ports detected 
[    3.466173] ehci-pci 0000:00:1d.0: EHCI Host Controller 
[    3.472111] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 2
[    3.480381] ehci-pci 0000:00:1d.0: debug port 2 
[    3.489571] ehci-pci 0000:00:1d.0: irq 18, io mem 0xc7101000 
[    3.501393] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00 
[    3.507855] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    3.515436] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.523500] usb usb2: Product: EHCI Host Controller 
[    3.528947] usb usb2: Manufacturer: Linux 4.4.110_pt_linux-v4.4.110 ehci_hcd
[    3.536816] usb usb2: SerialNumber: 0000:00:1d.0 
[    3.542107] hub 2-0:1.0: USB hub found 
[    3.546301] hub 2-0:1.0: 2 ports detected 
[    3.550942] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver 
[    3.557854] ohci-pci: OHCI PCI platform driver 
[    3.562844] uhci_hcd: USB Universal Host Controller Interface driver 
[    3.570032] usbcore: registered new interface driver usbserial 
[    3.576550] usbcore: registered new interface driver usbserial_generic
[    3.583844] usbserial: USB Serial support registered for generic 
[    3.590570] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    3.995383] tsc: Refined TSC clocksource calibration: 2195.099 MHz 
[    4.002289] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1fa41d170d9, max_idle_ns: 440795288527 ns 
[    4.046414] usb 2-1: new high-speed USB device number 2 using ehci-pci
[    4.174758] usb 2-1: New USB device found, idVendor=8087, idProduct=8002
[    4.182245] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    4.190382] hub 2-1:1.0: USB hub found 
[    4.194609] hub 2-1:1.0: 8 ports detected 
[    4.637363] i8042: No controller found 
[    4.641646] mousedev: PS/2 mouse device common for all mice 
[    4.648117] rtc_cmos 00:00: RTC can wake from S4 
[    4.653447] rtc_cmos 00:00: rtc core: registered rtc_cmos as rtc0 
[    4.660272] rtc_cmos 00:00: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[    4.669050] Intel P-state driver initializing. 
[    4.676630] EFI Variables Facility v0.08 2004-May-17

<hangs here>
Reboots after about 30 seconds.

Boots fine with nopti option.

Thank you,
Pavel

author maintainer
#73 lore raw
Quoted 91 lines · Pavel Tatashin

Hi Greg,

Just tested on my machine:

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.4.110_pt_linux-v4.4.110
(ptatashi@ca-ostest441) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC)
) #1 SMP Fri Jan 5 07:22:34 PST 2018
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.4.110_pt_linux-v4.4.110
root=UUID=fe908085-0117-442b-a57c-ce651cc95b38 ro crashkernel=auto
console=ttyS0,115200 LANG=en_US.UTF-8
[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    0.000000] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point
registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'
[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832

bytes, using 'standard' format.

<cut>

[    3.457106] hub 1-0:1.0: USB hub found
[    3.461298] hub 1-0:1.0: 2 ports detected
[    3.466173] ehci-pci 0000:00:1d.0: EHCI Host Controller
[    3.472111] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus
number 2
[    3.480381] ehci-pci 0000:00:1d.0: debug port 2
[    3.489571] ehci-pci 0000:00:1d.0: irq 18, io mem 0xc7101000
[    3.501393] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00
[    3.507855] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    3.515436] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[    3.523500] usb usb2: Product: EHCI Host Controller
[    3.528947] usb usb2: Manufacturer: Linux 4.4.110_pt_linux-v4.4.110
ehci_hcd
[    3.536816] usb usb2: SerialNumber: 0000:00:1d.0
[    3.542107] hub 2-0:1.0: USB hub found
[    3.546301] hub 2-0:1.0: 2 ports detected
[    3.550942] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    3.557854] ohci-pci: OHCI PCI platform driver
[    3.562844] uhci_hcd: USB Universal Host Controller Interface driver
[    3.570032] usbcore: registered new interface driver usbserial
[    3.576550] usbcore: registered new interface driver usbserial_generic
[    3.583844] usbserial: USB Serial support registered for generic
[    3.590570] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    3.995383] tsc: Refined TSC clocksource calibration: 2195.099 MHz
[    4.002289] clocksource: tsc: mask: 0xffffffffffffffff max_cycles:

0x1fa41d170d9, max_idle_ns: 440795288527 ns

[    4.046414] usb 2-1: new high-speed USB device number 2 using ehci-pci
[    4.174758] usb 2-1: New USB device found, idVendor=8087, idProduct=8002
[    4.182245] usb 2-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[    4.190382] hub 2-1:1.0: USB hub found
[    4.194609] hub 2-1:1.0: 8 ports detected
[    4.637363] i8042: No controller found
[    4.641646] mousedev: PS/2 mouse device common for all mice
[    4.648117] rtc_cmos 00:00: RTC can wake from S4
[    4.653447] rtc_cmos 00:00: rtc core: registered rtc_cmos as rtc0
[    4.660272] rtc_cmos 00:00: alarms up to one month, y3k, 114 bytes nvram,
hpet irqs
[    4.669050] Intel P-state driver initializing.
Quoted 5 lines
[    4.676630] EFI Variables Facility v0.08 2004-May-17

<hangs here>
Reboots after about 30 seconds.

Boots fine with nopti option.

Crap.

And 4.9.75 works for you just fine? Same with 4.15-rc6?

I'm wondering if this is some crazy gcc thing, given the ancient age of what you are using (gcc 4.8.5). I haven't used 4.x in many many years, is this what comes with RHEL6? What is the "base" distro you are building this on, and anything special about the hardware being used here?

Or is this a virtual machine? I've been seeing too many different crashes lately to keep them all straight, sorry...

thanks,

greg k-h

#74 lore raw
Quoted 1 line · Greg Kroah-Hartman

On Fri, Jan 05, 2018 at 10:32:49AM -0500, Pavel Tatashin wrote:

(...)

Quoted 6 lines
Quoted 3 lines

Reboots after about 30 seconds.

Boots fine with nopti option.

Crap.

Quoted 7 lines

And 4.9.75 works for you just fine? Same with 4.15-rc6?

I'm wondering if this is some crazy gcc thing, given the ancient age of what you are using (gcc 4.8.5). I haven't used 4.x in many many years, is this what comes with RHEL6? What is the "base" distro you are building this on, and anything special about the hardware being used here?

I don't think so, I'm personally building with 4.7.4 and am not seeing this with 4.4.110.

Willy

author maintainer
#75 lore raw
Quoted 11 lines · Willy Tarreau
Quoted 1 line · Greg Kroah-Hartman

On Fri, Jan 05, 2018 at 10:32:49AM -0500, Pavel Tatashin wrote:

(...)

Quoted 8 lines
Quoted 3 lines

Reboots after about 30 seconds.

Boots fine with nopti option.

Crap.

And 4.9.75 works for you just fine? Same with 4.15-rc6?

Quoted 8 lines
Quoted 5 lines

I'm wondering if this is some crazy gcc thing, given the ancient age of what you are using (gcc 4.8.5). I haven't used 4.x in many many years, is this what comes with RHEL6? What is the "base" distro you are building this on, and anything special about the hardware being used here?

I don't think so, I'm personally building with 4.7.4 and am not seeing this with 4.4.110.

Ok, looks like an efi issue...

greg k-h

#76 lore raw
In reply to Greg Kroah-Hartman
Quoted 4 lines

Crap.

And 4.9.75 works for you just fine? Same with 4.15-rc6?

4.15-rc6 -> Rebooted twice no issues. 4.9.75 -> Rebooted twice no issues 4.4.110 -> hangs/reboots on every single reboot.

Quoted 6 lines

I'm wondering if this is some crazy gcc thing, given the ancient age of what you are using (gcc 4.8.5). I haven't used 4.x in many many years, is this what comes with RHEL6? What is the "base" distro you are building this on, and anything special about the hardware being used here?

Oracle Linux 7.3

[root@ca-ostest441 ~]# cat /etc/oracle-release Oracle Linux Server release 7.3 [root@ca-ostest441 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.3 (Maipo)

Quoted 2 lines

Or is this a virtual machine? I've been seeing too many different crashes lately to keep them all straight, sorry...

This is a physical machine. No special devices attached:
http://www.oracle.com/us/products/servers/x6-2datasheet-2900789.pdf

[root@ca-ostest441 ~]# lscpu

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                40
On-line CPU(s) list:   0-39
Thread(s) per core:    2
Core(s) per socket:    10
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
Stepping:              1
CPU MHz:               2394.586
BogoMIPS:              4390.22
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              25600K
NUMA node0 CPU(s):     0-9,20-29
NUMA node1 CPU(s):     10-19,30-39

[root@ca-ostest441 ~]# free -h

              total        used        free      shared  buff/cache   available
Mem:           251G        2.7G        241G        9.1M        7.8G        247G
Swap:          4.0G          0B        4.0G
Quoted 4 lines

thanks,

greg k-h

#77 lore raw
In reply to Pavel Tatashin
Quoted 53 lines · Pavel Tatashin

Hi Greg,

Just tested on my machine:

[    0.000000] Initializing cgroup subsys cpuset 
[    0.000000] Initializing cgroup subsys cpu 
[    0.000000] Initializing cgroup subsys cpuacct 
[    0.000000] Linux version 4.4.110_pt_linux-v4.4.110 (ptatashi@ca-ostest441) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) ) #1 SMP Fri Jan 5 07:22:34 PST 2018
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.4.110_pt_linux-v4.4.110 root=UUID=fe908085-0117-442b-a57c-ce651cc95b38 ro crashkernel=auto console=ttyS0,115200 LANG=en_US.UTF-8
[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256 
[    0.000000] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers' 
[    0.000000] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers' 
[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. 
<cut>
[    3.457106] hub 1-0:1.0: USB hub found 
[    3.461298] hub 1-0:1.0: 2 ports detected 
[    3.466173] ehci-pci 0000:00:1d.0: EHCI Host Controller 
[    3.472111] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 2
[    3.480381] ehci-pci 0000:00:1d.0: debug port 2 
[    3.489571] ehci-pci 0000:00:1d.0: irq 18, io mem 0xc7101000 
[    3.501393] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00 
[    3.507855] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    3.515436] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.523500] usb usb2: Product: EHCI Host Controller 
[    3.528947] usb usb2: Manufacturer: Linux 4.4.110_pt_linux-v4.4.110 ehci_hcd
[    3.536816] usb usb2: SerialNumber: 0000:00:1d.0 
[    3.542107] hub 2-0:1.0: USB hub found 
[    3.546301] hub 2-0:1.0: 2 ports detected 
[    3.550942] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver 
[    3.557854] ohci-pci: OHCI PCI platform driver 
[    3.562844] uhci_hcd: USB Universal Host Controller Interface driver 
[    3.570032] usbcore: registered new interface driver usbserial 
[    3.576550] usbcore: registered new interface driver usbserial_generic
[    3.583844] usbserial: USB Serial support registered for generic 
[    3.590570] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    3.995383] tsc: Refined TSC clocksource calibration: 2195.099 MHz 
[    4.002289] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1fa41d170d9, max_idle_ns: 440795288527 ns 
[    4.046414] usb 2-1: new high-speed USB device number 2 using ehci-pci
[    4.174758] usb 2-1: New USB device found, idVendor=8087, idProduct=8002
[    4.182245] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    4.190382] hub 2-1:1.0: USB hub found 
[    4.194609] hub 2-1:1.0: 8 ports detected 
[    4.637363] i8042: No controller found 
[    4.641646] mousedev: PS/2 mouse device common for all mice 
[    4.648117] rtc_cmos 00:00: RTC can wake from S4 
[    4.653447] rtc_cmos 00:00: rtc core: registered rtc_cmos as rtc0 
[    4.660272] rtc_cmos 00:00: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[    4.669050] Intel P-state driver initializing. 
[    4.676630] EFI Variables Facility v0.08 2004-May-17
Quoted 3 lines

<hangs here>
Reboots after about 30 seconds.

This looks like the KVM RSM issue. When you manage to run a buggy configuration (KVM + OVMF with secure boot support in the host, PCID (PTI or otherwise) and SMP in the guest), the first EFI call after AP bringup dies.

The actual failure is nasty. When one CPU calls into EFI, all the other CPUs die --they enter SMM and they don't come back out correctly. I think the best the guest could do is to try to generate a useful printk if this happens.

Update your host.

Quoted 4 lines

Boots fine with nopti option.

Thank you,
Pavel

#78 lore raw

Hi Andy,

This is bare metal, not VM, read my other email in this thread about the machine on which I am testing. Sometime hang happens a little later:

[    5.088948] microcode: CPU36 sig=0x406f1, pf=0x1, revision=0xb00001d
[    5.096076] microcode: CPU37 sig=0x406f1, pf=0x1, revision=0xb00001d
[    5.103206] microcode: CPU38 sig=0x406f1, pf=0x1, revision=0xb00001d
[    5.110326] microcode: CPU39 sig=0x406f1, pf=0x1, revision=0xb00001d
[    5.117467] microcode: Microcode Update Driver: v2.01
<[email protected]>, Peter Oruba
[    5.127476] registered taskstats version 1
[    5.132058] Loading compiled-in X.509 certificates
[    5.138206] Loaded X.509 cert 'Build time autogenerated kernel key:
26871d9e2c53359981a91797284d4f630796d8cf'
[    5.149337] zswap: loaded using pool lzo/zbud
[    5.154215] page_owner is disabled
[    5.161468] Key type trusted registered
[    5.169226] Key type encrypted registered
[    5.173719] ima: No TPM chip found, activating TPM-bypass!
[    5.179918] evm: HMAC attrs: 0x1
[    5.184958] rtc_cmos 00:00: setting system clock to 2018-01-05
15:40:45 UTC (1515166845)
[    5.196099] Freeing unused kernel memory: 1856K

<hang / reboot here>

Thank you,
Pavel

#79 lore raw
Quoted 28 lines · Pavel Tatashin

Hi Andy,

This is bare metal, not VM, read my other email in this thread about the machine on which I am testing. Sometime hang happens a little later:

[    5.088948] microcode: CPU36 sig=0x406f1, pf=0x1, revision=0xb00001d
[    5.096076] microcode: CPU37 sig=0x406f1, pf=0x1, revision=0xb00001d
[    5.103206] microcode: CPU38 sig=0x406f1, pf=0x1, revision=0xb00001d
[    5.110326] microcode: CPU39 sig=0x406f1, pf=0x1, revision=0xb00001d
[    5.117467] microcode: Microcode Update Driver: v2.01
<[email protected]>, Peter Oruba
[    5.127476] registered taskstats version 1
[    5.132058] Loading compiled-in X.509 certificates
[    5.138206] Loaded X.509 cert 'Build time autogenerated kernel key:
26871d9e2c53359981a91797284d4f630796d8cf'
[    5.149337] zswap: loaded using pool lzo/zbud
[    5.154215] page_owner is disabled
[    5.161468] Key type trusted registered
[    5.169226] Key type encrypted registered
[    5.173719] ima: No TPM chip found, activating TPM-bypass!
[    5.179918] evm: HMAC attrs: 0x1
[    5.184958] rtc_cmos 00:00: setting system clock to 2018-01-05
15:40:45 UTC (1515166845)
[    5.196099] Freeing unused kernel memory: 1856K
Quoted 1 line

<hang / reboot here>

Gah, too many emails.

Someone probably just needs to look at the EFI think code. Does it boot if you disable EFI support in the kernel (noefi boot option, I think, or maybe just compile it out.

Quoted 3 lines

Thank you,
Pavel

#80 lore raw

Boots successfully with "noefi" kernel parameter :)

Quoted 39 lines · Andy Lutomirski
Quoted 28 lines · Pavel Tatashin

Hi Andy,

This is bare metal, not VM, read my other email in this thread about the machine on which I am testing. Sometime hang happens a little later:

[    5.088948] microcode: CPU36 sig=0x406f1, pf=0x1, revision=0xb00001d
[    5.096076] microcode: CPU37 sig=0x406f1, pf=0x1, revision=0xb00001d
[    5.103206] microcode: CPU38 sig=0x406f1, pf=0x1, revision=0xb00001d
[    5.110326] microcode: CPU39 sig=0x406f1, pf=0x1, revision=0xb00001d
[    5.117467] microcode: Microcode Update Driver: v2.01
<[email protected]>, Peter Oruba
[    5.127476] registered taskstats version 1
[    5.132058] Loading compiled-in X.509 certificates
[    5.138206] Loaded X.509 cert 'Build time autogenerated kernel key:
26871d9e2c53359981a91797284d4f630796d8cf'
[    5.149337] zswap: loaded using pool lzo/zbud
[    5.154215] page_owner is disabled
[    5.161468] Key type trusted registered
[    5.169226] Key type encrypted registered
[    5.173719] ima: No TPM chip found, activating TPM-bypass!
[    5.179918] evm: HMAC attrs: 0x1
[    5.184958] rtc_cmos 00:00: setting system clock to 2018-01-05
15:40:45 UTC (1515166845)
[    5.196099] Freeing unused kernel memory: 1856K
Quoted 1 line

<hang / reboot here>

Gah, too many emails.

Someone probably just needs to look at the EFI think code. Does it boot if you disable EFI support in the kernel (noefi boot option, I think, or maybe just compile it out.

Quoted 3 lines

Thank you,
Pavel

author maintainer
#81 lore raw
Quoted 1 line · Pavel Tatashin

Boots successfully with "noefi" kernel parameter :)

Thanks, that will help me narrow it down. I'll dig through more patches when I get home tonight...

greg k-h

#82 lore raw
Quoted 5 lines · Greg Kroah-Hartman
Quoted 1 line · Pavel Tatashin

Boots successfully with "noefi" kernel parameter :)

Thanks, that will help me narrow it down. I'll dig through more patches when I get home tonight...

I wish you luck. The 4.4 series is "KAISER", not "KPTI", and the relevant code is spread all over the place and is generally garbage. See, for example, the turd called kaiser_set_shadow_pgd(). I would not be terribly surprised if that particular turd is biting here.

An alternative theory is that something is screwy in the EFI code. I don't see anything directly wrong, but it's certainly a bit sketchy. The newer kernels carefully avoid using PCID 0 for real work to avoid corruption due to EFI and similar things. The "KAISER" code has no such mitigation. Fortunately, it seems to use PCID=0 for kernel and PCID=nonzero for user, so the obvious problem isn't present, but something could still be wrong.

Pavel, can you send your /proc/cpuinfo on a noefi boot? (Just the first CPU worth is fine.)

FWIW, I said before that I have very little desire to help debug "KAISER". I stand by that.

#83 lore raw
Quoted 2 lines

Pavel, can you send your /proc/cpuinfo on a noefi boot? (Just the first CPU worth is fine.)

With noefi option:

[root@ca-ostest441 ~]# more /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
stepping : 1
microcode : 0xb00001d
cpu MHz : 1971.406
cache size : 25600 KB
physical id : 0
siblings : 20
core id : 0
cpu cores : 10
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 20
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdt scp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc ap erfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg
fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_time
r aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat epb invpcid_singl e pln pts dtherm intel_pt kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdseed adx smap xsaveopt
cqm_llc cqm_occup_llc

bugs            :
bogomips        : 4390.08
clflush size    : 64

cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:

#84 lore raw

I hoped, this patch would fix the efi issue:
https://lkml.org/lkml/2018/1/5/534

But, unfortunatly it does not. I got a partial panic message this time:

[    4.737578] usb 1-1: new high-speed USB device number 2 using ehci-pci
[    4.846712] BUG: unable to handle kernel paging request at 0000000000017e10
[    4.854509] IP: [<ffffffff810ce77e>]
native_queued_spin_lock_slowpath+0xfe/0x170
[    4.862780] PGD 0
[    4.865034] Oops: 0002 [#1] SMP
[    4.868657] Modules linked in:
[    4.872075] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.4.110_pt_linux-v4.4.110 #3
[    4.880526] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
[    4.891596] task: ffffffff81aab500 ti: ffffffff81a98000 task.ti:
ffffffff81a98000
[    4.899950] RIP: 0010:[<ffffffff810ce77e>]  [<ffffffff810ce77e>]
native_queued_spin_lock_slowpath+0xfe/0x170
[    4.910936] RSP: 0000:ffff881fff803c88  EFLAGS: 00010002
[    4.916865] RAX: 000000000000206b RBX: ffff88407e611900 RCX: ffff881fff817e00
[    4.924831] RDX: 0000000000017e10 RSI: 0000000000040000 RDI: ffff88407e611a58
[    4.932797] RBP: ffff881fff803c88 R08: 0000000000000101 R09: 0000000000000000
[    4.940764] R10: 000000005c96d000 R11: ffff88005c96d0c0 R12: ffff881ff25e52c8
[    4.948730] R13: ffff88407e6d1900 R14: ffff881fff8118c0 R15: ffff88407e6118c0
[    4.956696] FS:  0000000000000000(0000) GS:ffff881fff800000(0000)
knlGS:0000000000000000
[    4.965727] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    4.972140] CR2: 0000000000017e10 CR3: 0000000001aa2000 CR4: 00000000003606
Quoted 40 lines · Pavel Tatashin
Quoted 2 lines

Pavel, can you send your /proc/cpuinfo on a noefi boot? (Just the first CPU worth is fine.)

With noefi option:

[root@ca-ostest441 ~]# more /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
stepping : 1
microcode : 0xb00001d
cpu MHz : 1971.406
cache size : 25600 KB
physical id : 0
siblings : 20
core id : 0
cpu cores : 10
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 20
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdt scp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc ap erfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg
fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_time
r aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat epb invpcid_singl e pln pts dtherm intel_pt kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdseed adx smap xsaveopt
cqm_llc cqm_occup_llc

bugs            :
bogomips        : 4390.08
clflush size    : 64

cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:

#85 lore raw

Actually it helps, if before 4.4.110 never booted on my machine, not i was able to boot on a second try.

Quoted 73 lines · Pavel Tatashin

I hoped, this patch would fix the efi issue:
https://lkml.org/lkml/2018/1/5/534

But, unfortunatly it does not. I got a partial panic message this time:

[    4.737578] usb 1-1: new high-speed USB device number 2 using ehci-pci
[    4.846712] BUG: unable to handle kernel paging request at 0000000000017e10
[    4.854509] IP: [<ffffffff810ce77e>]
native_queued_spin_lock_slowpath+0xfe/0x170
[    4.862780] PGD 0
[    4.865034] Oops: 0002 [#1] SMP
[    4.868657] Modules linked in:
[    4.872075] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.4.110_pt_linux-v4.4.110 #3
[    4.880526] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
[    4.891596] task: ffffffff81aab500 ti: ffffffff81a98000 task.ti:
ffffffff81a98000
[    4.899950] RIP: 0010:[<ffffffff810ce77e>]  [<ffffffff810ce77e>]
native_queued_spin_lock_slowpath+0xfe/0x170
[    4.910936] RSP: 0000:ffff881fff803c88  EFLAGS: 00010002
[    4.916865] RAX: 000000000000206b RBX: ffff88407e611900 RCX: ffff881fff817e00
[    4.924831] RDX: 0000000000017e10 RSI: 0000000000040000 RDI: ffff88407e611a58
[    4.932797] RBP: ffff881fff803c88 R08: 0000000000000101 R09: 0000000000000000
[    4.940764] R10: 000000005c96d000 R11: ffff88005c96d0c0 R12: ffff881ff25e52c8
[    4.948730] R13: ffff88407e6d1900 R14: ffff881fff8118c0 R15: ffff88407e6118c0
[    4.956696] FS:  0000000000000000(0000) GS:ffff881fff800000(0000)
knlGS:0000000000000000
[    4.965727] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    4.972140] CR2: 0000000000017e10 CR3: 0000000001aa2000 CR4: 00000000003606
Quoted 40 lines · Pavel Tatashin
Quoted 2 lines

Pavel, can you send your /proc/cpuinfo on a noefi boot? (Just the first CPU worth is fine.)

With noefi option:

[root@ca-ostest441 ~]# more /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
stepping : 1
microcode : 0xb00001d
cpu MHz : 1971.406
cache size : 25600 KB
physical id : 0
siblings : 20
core id : 0
cpu cores : 10
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 20
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdt scp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc ap erfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg
fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_time
r aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat epb invpcid_singl e pln pts dtherm intel_pt kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdseed adx smap xsaveopt
cqm_llc cqm_occup_llc

bugs            :
bogomips        : 4390.08
clflush size    : 64

cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:

author maintainer
#86 lore raw
Quoted 2 lines · Pavel Tatashin

Actually it helps, if before 4.4.110 never booted on my machine, not i was able to boot on a second try.

Wait, what? This has never booted on 4.4.x before? Did 4.4.108 work? 109? Are you sure this hardware even works? :)

thanks,

greg k-h

#87 lore raw

The hardware works :) I meant that before the patch linked in https://lkml.org/lkml/2018/1/5/534, I was never able to boot 4.4.110. But with that patch applied, I was able to boot it at least once, but it could be accidental. The hang/panic does not happen at the same time on every boot.

Pasha

Quoted 11 lines · Greg Kroah-Hartman
Quoted 2 lines · Pavel Tatashin

Actually it helps, if before 4.4.110 never booted on my machine, not i was able to boot on a second try.

Wait, what? This has never booted on 4.4.x before? Did 4.4.108 work? 109? Are you sure this hardware even works? :)

thanks,

greg k-h

#88 lore raw
Quoted 5 lines · Pavel Tatashin

The hardware works :) I meant that before the patch linked in
https://lkml.org/lkml/2018/1/5/534, I was never able to boot 4.4.110. But with that patch applied, I was able to boot it at least once, but it could be accidental. The hang/panic does not happen at the same time on every boot.

I get the feeling that it was accidental: it seems to me that you have a memory corruption problem, that gets shifted around by the different patches (or "noefi" or "nopti").

Because yesterday your boots were able to get way beyond the "EFI Variables Facility" message, and I can't imagine why the EFI issue would not have been equally debilitating on yesterday's 110-rc, if it were in play.

I did intend to ask you to send your System.map, for us to scan
through: maybe some variable is marked __init and should not be, then the "Freeing unused kernel memory" frees it for random reuse.

But today you didn't get anywhere near the "Freeing unused kernel memory", so that can't be it - or do you sometimes get that far today?

You mention that the hang/panic does not happen at the same time on every boot: I think all I can ask is for you to keep supplying us with different examples (console messages) of where it occurs, in the hope that one of them will point us in the right direction.

And it even seems possible that this has nothing to do with the 4.4.110 changes - that 4.4.109 plus some other random patches would unleash similar corruption. Though on balance that does seem unlikely.

Hugh

Quoted 20 lines

Pasha

Quoted 14 lines · Greg Kroah-Hartman
Quoted 3 lines · Pavel Tatashin

Actually it helps, if before 4.4.110 never booted on my machine, not i was able to boot on a second try.

Wait, what? This has never booted on 4.4.x before? Did 4.4.108 work? 109? Are you sure this hardware even works? :)

thanks,

greg k-h

#89 lore raw

Hi Hugh,

Thank you very much for your very thoughtful input.

I quiet positive this problem is PTI regression, because exactly the same problem I see with kernel 4.1 to which I back-ported all the necessary PTI patches from 4.4.110. I will provide this thread with more information as I collect it. I will also try to root cause the problem.

The bug has memory corruption behavior, but with both 4.1 and 4.4 kernels problem goes away when I boot with noefi parameter. So, EFI + PTI is the culprit for this memory corruption.

Thank you,
Pavel

Quoted 34 lines · Hugh Dickins
Quoted 5 lines · Pavel Tatashin

The hardware works :) I meant that before the patch linked in
https://lkml.org/lkml/2018/1/5/534, I was never able to boot 4.4.110. But with that patch applied, I was able to boot it at least once, but it could be accidental. The hang/panic does not happen at the same time on every boot.

I get the feeling that it was accidental: it seems to me that you have a memory corruption problem, that gets shifted around by the different patches (or "noefi" or "nopti").

Because yesterday your boots were able to get way beyond the "EFI Variables Facility" message, and I can't imagine why the EFI issue would not have been equally debilitating on yesterday's 110-rc, if it were in play.

I did intend to ask you to send your System.map, for us to scan
through: maybe some variable is marked __init and should not be, then the "Freeing unused kernel memory" frees it for random reuse.

But today you didn't get anywhere near the "Freeing unused kernel memory", so that can't be it - or do you sometimes get that far today?

You mention that the hang/panic does not happen at the same time on every boot: I think all I can ask is for you to keep supplying us with different examples (console messages) of where it occurs, in the hope that one of them will point us in the right direction.

And it even seems possible that this has nothing to do with the 4.4.110 changes - that 4.4.109 plus some other random patches would unleash similar corruption. Though on balance that does seem unlikely.

Hugh

author maintainer
#90 lore raw
In reply to Pavel Tatashin
Quoted 5 lines · Pavel Tatashin

The hardware works :) I meant that before the patch linked in
https://lkml.org/lkml/2018/1/5/534, I was never able to boot 4.4.110. But with that patch applied, I was able to boot it at least once, but it could be accidental. The hang/panic does not happen at the same time on every boot.

Any chance you can grab the latest SLES 12 kernel and run it with pti and efi enabled to see if that works properly for you or not? I trust SUSE's testing of their kernel, and odds are I'm just missing one of their many other patches they have in their tree for other issues that they have seen in the past.

If you want, I can just send you the full patch that they run on top of the latest 4.4 stable tree, so you don't have to dig it out of their git repo if you can't find the binary image.

thanks,

greg k-h

#91 lore raw

Hi Greg,

I cloned and built suse12, and it does not have issues with EFI + PTI (kaiser) on my machine.

BTW, i have also reproduced this problem on another machine with the same configuration, therefore, it is not specific only to one box. Also, as I mentioned earlier I am seeing the same issue with 4.1 + kaiser patches taken from 4.4.110.

Thank you,
Pavel

Quoted 20 lines · Greg Kroah-Hartman
Quoted 5 lines · Pavel Tatashin

The hardware works :) I meant that before the patch linked in
https://lkml.org/lkml/2018/1/5/534, I was never able to boot 4.4.110. But with that patch applied, I was able to boot it at least once, but it could be accidental. The hang/panic does not happen at the same time on every boot.

Any chance you can grab the latest SLES 12 kernel and run it with pti and efi enabled to see if that works properly for you or not? I trust SUSE's testing of their kernel, and odds are I'm just missing one of their many other patches they have in their tree for other issues that they have seen in the past.

If you want, I can just send you the full patch that they run on top of the latest 4.4 stable tree, so you don't have to dig it out of their git repo if you can't find the binary image.

thanks,

greg k-h

#92 lore raw

Hi Greg,

I reverted suse12 back to:
13dae54cb229d078635f159dd8afe16ae683980b x86/kaiser: Move feature detection up (bsc#1068032).

And, still do not see the problem. So, whatever fixes the issue comes before kaiser.

Pavel

Quoted 35 lines · Pavel Tatashin

Hi Greg,

I cloned and built suse12, and it does not have issues with EFI + PTI (kaiser) on my machine.

BTW, i have also reproduced this problem on another machine with the same configuration, therefore, it is not specific only to one box. Also, as I mentioned earlier I am seeing the same issue with 4.1 + kaiser patches taken from 4.4.110.

Thank you,
Pavel

Quoted 20 lines · Greg Kroah-Hartman
Quoted 5 lines · Pavel Tatashin

The hardware works :) I meant that before the patch linked in
https://lkml.org/lkml/2018/1/5/534, I was never able to boot 4.4.110. But with that patch applied, I was able to boot it at least once, but it could be accidental. The hang/panic does not happen at the same time on every boot.

Any chance you can grab the latest SLES 12 kernel and run it with pti and efi enabled to see if that works properly for you or not? I trust SUSE's testing of their kernel, and odds are I'm just missing one of their many other patches they have in their tree for other issues that they have seen in the past.

If you want, I can just send you the full patch that they run on top of the latest 4.4 stable tree, so you don't have to dig it out of their git repo if you can't find the binary image.

thanks,

greg k-h

author maintainer
#93 lore raw
Quoted 8 lines · Pavel Tatashin

Hi Greg,

I reverted suse12 back to:
13dae54cb229d078635f159dd8afe16ae683980b x86/kaiser: Move feature detection up (bsc#1068032).

And, still do not see the problem. So, whatever fixes the issue comes before kaiser.

Ok, thanks for the hint.

As I can't duplicate this here at all, any specifics as to what hardware/procesor type this is?

I can punt and say just "use 4.9 on this hardware if you have it", right? :)

I'll try to dig through the sles kernel some more, but given it is 20000 patches, and I can't actually test the problem myself, it's not exactly easy going...

greg k-h

#94 lore raw

Hi Greg,

Quoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Pavel Tatashin

Hi Greg,

I reverted suse12 back to:
13dae54cb229d078635f159dd8afe16ae683980b x86/kaiser: Move feature detection up (bsc#1068032).

Quoted 8 lines
Quoted 2 lines

And, still do not see the problem. So, whatever fixes the issue comes before kaiser.

Ok, thanks for the hint.

As I can't duplicate this here at all, any specifics as to what hardware/procesor type this is?

BIOS:
Version 2.17.1249. Copyright (C) 2016 American Megatrends, Inc. BIOS Date: 08/30/2016 10:35:36 Ver: 38050100

ca-ostest442:linux-stable$ lscpu

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                40
On-line CPU(s) list:   0-39
Thread(s) per core:    2
Core(s) per socket:    10
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
Stepping:              1
CPU MHz:               1738.601
BogoMIPS:              4396.18
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              25600K
NUMA node0 CPU(s):     0-9,20-29
NUMA node1 CPU(s):     10-19,30-39

Note, if I boot with nr_cpus=1, hang never happens, with nr_cpus=4 happens but seldomly, and with all 40 CPUs happens on almost every reboot.

As Hugh Dickins suggested, I am going to show panic outputs, as I get them. Here is one more panic (note output is not complete because machine reboots):

[    6.276456] EFI Variables Facility v0.08 2004-May-17
[    6.384665] BUG: unable to handle kernel paging request at
ffff901fff5a6000
[    6.392461] IP: [<ffffffff8106bb08>] vmalloc_fault+0x1f8/0x340
[    6.398987] PGD 0
[    6.401242] Oops: 0000 [#1] SMP
[    6.404866] Modules linked in:
[    6.408287] CPU: 10 PID: 0 Comm: swapper/10 Not tainted
4.4.110_pt_stable #2
[    6.416156] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 3
8050100 08/30/2016
[    6.427226] task: ffff883ff1e28000 ti: ffff883ff1e24000 task.ti:
ffff883ff1e24000
[    6.435580] RIP: 0010:[<ffffffff8106bb08>]  [<ffffffff8106bb08>]
vmalloc_fault+0x1f8/0x340
[    6.444819] RSP: 0000:ffff883ff1e27cc0  EFLAGS: 00010086
[    6.450749] RAX: ffff881fff5a6058 RBX: 00003ffffffff000 RCX:
0000081fff5a6000
[    6.458714] RDX: ffff880000000000 RSI: ffff901fff5a6000 RDI:
0000000000000000
[    6.466681] RBP: ffff883ff1e27cf0 R08: 0000000000000018 R09:
000000000002d2de
[    6.474647] R10: 0000000000032ef3 R11: 0000000000002e04 R12:
ffffc900000000f0
[    6.482615] R13: ffff880000000000 R14: ffff901fff5a6000 R15:
ffff881fff5a6000
[    6.490574] FS:  0000000000000000(0000) GS:ffff88407e600000(0000)
knlGS:0000000000000000
[    6.499607] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.506022] CR2: ffff901fff5a6000 CR3: 0000000001aa2000 CR4:
0000000000360670
[    6.513989] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[    6.521956] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[    6.529923] Stack:
[    6.532169]  ffff881fff5a6000[    6.532405] ------------[ cut here
]------------
[    6.532414] WARNING: CPU: 22 PID: 162
#95 lore raw

Here is one more:

[    6.284763] EFI Variables Facility v0.08 2004-May-17
[    6.555990] ------------[ cut here ]------------
[    6.561145] kernel BUG at
/scratch/ptatashi/linux-stable/mm/slub.c:3627!
[    6.568625] invalid opcode: 0000 [#1] SMP
[    6.573219] Modules linked in:
[    6.576639] CPU: 1 PID: 364 Comm: kworker/1:1 Not tainted
4.4.110_pt_stable #3
[    6.584692] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 38050100 08/30/2016
[    6.595766] Workqueue: events clocksource_watchdog_work
[    6.601611] task: ffff881fecd82b00 ti: ffff881fecda4000 task.ti:
ffff881fecda4000
[    6.609963] RIP: 0010:[<ffffffff811e704a>]  [<ffffffff811e704a>]
kfree+0x14a/0x150
[    6.618419] RSP: 0000:ffff881fecda7d40  EFLAGS: 00010246
[    6.624348] RAX: ffffffff8106c280 RBX: ffff883ff114bfc0 RCX:
00000000ffffffd8
[    6.632314] RDX: 000077ff80000000 RSI: 0000000000000246 RDI:
ffff883ff114bfc0
[    6.640280] RBP: ffff881fecda7d58 R08: 0000000000000000 R09:
ffff881fff917300
[    6.648244] R10: 0000000000000000 R11: ffffea00ffc452c0 R12:
ffff883fec2f4080
[    6.656208] R13: ffffffff810a5bee R14: 00000000ffffffff R15:
0000000000000000
[    6.664175] FS:  0000000000000000(0000) GS:ffff881fff840000(0000)
knlGS:0000000000000000
[    6.673208] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.679623] CR2: 0000000000000000 CR3: 0000000001aa2000 CR4:
0000000000360670
[    6.687587] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[    6.695553] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[    6.703516] Stack:
[    6.705759]  ffff883ff114bfc0 ffff883fec2f4080 ffffffff819a26e8
ffff881fecda7e00
[    6.714061]  ffffffff810a5bee ffff881f00000020 ffff881fecda7e10
ffff881fecda7da8
[    6.722363]  ffffffff00000000 ffff881f00000000 ffff881fecda7d90
ffff881fecda7d90
[    6.730666] Call Trace:
[    6.733400]  [<ffffffff810a5bee>]
kthread_create_on_node+0x14e/0x1a0
[    6.740495]  [<ffffffff810f9dd5>]
clocksource_watchdog_work+0x25/0x40
[    6.747679]  [<ffffffff8109ef6f>] process_one_work+0x14f/0x400
[    6.754181]  [<ffffffff8109fbc4>] worker_thread+0x114/0x480
[    6.760402]  [<ffffffff8109fab0>] ? rescuer_thread+0x310/0x310
[    6.766913]  [<ffffffff810a56b5>] kthread+0xe5/0x100
[    6.772456]  [<ffffffff810a55d0>] ? kthread_park+0x60/0x60
[    6.778580]  [<ffffffff8170fa0f>] ret_from_fork+0x3f/0x70
[    6.784608]  [<ffffffff810a55d0>] ? kthread_park+0x60/0x60
[    6.790721] Code: 8b 03 31 f6 f6 c4 40 74 04 41 8b 73 6c 4c 89 df
e8 1c a8 fa ff e9 73 ff ff ff 4c 8d 58 ff e9 20 ff ff ff 49 8b 43 20
a8 01 75 d4 <0f> 0b 0f 1f 40 00 0f 1f 44 00 00 55 48 89 e5 41 57 41 56
41 55
[    6.812429] RIP  [<ffffffff811e704a>] kfree+0x14a/0x150
[    6.818273]  RSP <ffff881fecda7d40>
[    6.822177] ---[ end trace 4ce44d21c6d68eed ]---
Quoted 99 lines · Pavel Tatashin

Hi Greg,

Quoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Pavel Tatashin

Hi Greg,

I reverted suse12 back to:
13dae54cb229d078635f159dd8afe16ae683980b x86/kaiser: Move feature detection up (bsc#1068032).

Quoted 8 lines
Quoted 2 lines

And, still do not see the problem. So, whatever fixes the issue comes before kaiser.

Ok, thanks for the hint.

As I can't duplicate this here at all, any specifics as to what hardware/procesor type this is?

BIOS:
Version 2.17.1249. Copyright (C) 2016 American Megatrends, Inc. BIOS Date: 08/30/2016 10:35:36 Ver: 38050100

ca-ostest442:linux-stable$ lscpu

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                40
On-line CPU(s) list:   0-39
Thread(s) per core:    2
Core(s) per socket:    10
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
Stepping:              1
CPU MHz:               1738.601
BogoMIPS:              4396.18
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              25600K
NUMA node0 CPU(s):     0-9,20-29
NUMA node1 CPU(s):     10-19,30-39

Note, if I boot with nr_cpus=1, hang never happens, with nr_cpus=4 happens but seldomly, and with all 40 CPUs happens on almost every reboot.

As Hugh Dickins suggested, I am going to show panic outputs, as I get them. Here is one more panic (note output is not complete because machine reboots):

[    6.276456] EFI Variables Facility v0.08 2004-May-17
[    6.384665] BUG: unable to handle kernel paging request at
ffff901fff5a6000
[    6.392461] IP: [<ffffffff8106bb08>] vmalloc_fault+0x1f8/0x340
[    6.398987] PGD 0
[    6.401242] Oops: 0000 [#1] SMP
[    6.404866] Modules linked in:
[    6.408287] CPU: 10 PID: 0 Comm: swapper/10 Not tainted
4.4.110_pt_stable #2
[    6.416156] Hardware name: Oracle Corporation ORACLE SERVER
X6-2/ASM,MOTHERBOARD,1U, BIOS 3
8050100 08/30/2016
[    6.427226] task: ffff883ff1e28000 ti: ffff883ff1e24000 task.ti:
ffff883ff1e24000
[    6.435580] RIP: 0010:[<ffffffff8106bb08>]  [<ffffffff8106bb08>]
vmalloc_fault+0x1f8/0x340
[    6.444819] RSP: 0000:ffff883ff1e27cc0  EFLAGS: 00010086
[    6.450749] RAX: ffff881fff5a6058 RBX: 00003ffffffff000 RCX:
0000081fff5a6000
[    6.458714] RDX: ffff880000000000 RSI: ffff901fff5a6000 RDI:
0000000000000000
[    6.466681] RBP: ffff883ff1e27cf0 R08: 0000000000000018 R09:
000000000002d2de
[    6.474647] R10: 0000000000032ef3 R11: 0000000000002e04 R12:
ffffc900000000f0
[    6.482615] R13: ffff880000000000 R14: ffff901fff5a6000 R15:
ffff881fff5a6000
[    6.490574] FS:  0000000000000000(0000) GS:ffff88407e600000(0000)
knlGS:0000000000000000
[    6.499607] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    6.506022] CR2: ffff901fff5a6000 CR3: 0000000001aa2000 CR4:
0000000000360670
[    6.513989] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[    6.521956] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[    6.529923] Stack:
[    6.532169]  ffff881fff5a6000[    6.532405] ------------[ cut here
]------------
[    6.532414] WARNING: CPU: 22 PID: 162
Reviewed-by Steven Sistare
#96 lore raw

I have root caused the memory corruption panics/hangs that I've been experiencing during boot with the latest 4.4.110 kernel. The problem as was suspected by Andy Lutomirski is with interaction between PTI and EFI. It may affect any system that has EFI bios. I have not verified if it can affect any other kernel beside 4.4.110

Attached is the fix for this issue with explanations that Steve Sistare and I developed.

From 1189f3568a90ddd40e1418b9687def5d89153ee3 Mon Sep 17 00:00:00 2001
From: Pavel Tatashin <[email protected]>
Date: Thu, 11 Jan 2018 06:50:25 -0800
Subject: [PATCH] x86/pti/efi: broken conversion from efi to kernel page table

In entry_64.S we have code like this:

    /* Unconditionally use kernel CR3 for do_nmi() */
    /* %rax is saved above, so OK to clobber here */
    ALTERNATIVE "jmp 2f", "movq %cr3, %rax", X86_FEATURE_KAISER
    /* If PCID enabled, NOFLUSH now and NOFLUSH on return */
    ALTERNATIVE "", "bts $63, %rax", X86_FEATURE_PCID
    pushq   %rax
    /* mask off "user" bit of pgd address and 12 PCID bits: */
    andq    $(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax
    movq    %rax, %cr3

2:

    /* paranoidentry do_nmi, 0; without TRACE_IRQS_OFF */
    call    do_nmi

With this instruction:

    andq    $(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax

We unconditionally switch from whatever our CR3 was to kernel page table. But, in arch/x86/platform/efi/efi_64.c We temporarily set a different page table, that does not have the kernel page table with 0x1000 offset from it.

Look in efi_thunk() and efi_thunk_set_virtual_address_map().

So, while CR3 points to the other page table, we get an NMI interrupt, and clear 0x1000 from CR3, resulting in a bogus CR3 if the 0x1000 bit was set.

The efi page table comes from realmode/rm/trampoline_64.S:

arch/x86/realmode/rm/trampoline_64.S

141 .bss
142 .balign PAGE_SIZE
143 GLOBAL(trampoline_pgd) .space PAGE_SIZE

Notice: alignment is PAGE_SIZE, so after applying KAISER_SHADOW_PGD_OFFSET which equal to PAGE_SIZE, we can get a different page table.

But, even if we fix alignment, here the trampoline binary is later copied into dynamically allocated memory in reserve_real_mode(), so we need to fix that place as well.

Fixes 8a43ddfb93a0 ("KAISER: Kernel Address Isolation")
---
 arch/x86/include/asm/kaiser.h        | 8 ++++++++
 arch/x86/realmode/init.c             | 4 +++-
 arch/x86/realmode/rm/trampoline_64.S | 3 ++-
 3 files changed, 13 insertions(+), 2 deletions(-)
arch/x86/include/asm/kaiser.h +8 -0
index 802bbbdfe143..e087bd7a8d29 100644
@@ -19,6 +19,12 @@
 
 #define KAISER_SHADOW_PGD_OFFSET 0x1000
 
+/*
+ *  A page table address must have this alignment to stay the same when
+ *  KAISER_SHADOW_PGD_OFFSET mask is applied
+ */
+#define KAISER_KERNEL_PGD_ALIGNMENT (KAISER_SHADOW_PGD_OFFSET << 1)
+
 #ifdef __ASSEMBLY__
 #ifdef CONFIG_PAGE_TABLE_ISOLATION
 
@@ -71,6 +77,8 @@ movq PER_CPU_VAR(unsafe_stack_register_backup), %rax
 
 #else /* CONFIG_PAGE_TABLE_ISOLATION */
 
+#define KAISER_KERNEL_PGD_ALIGNMENT PAGE_SIZE
+
 .macro SWITCH_KERNEL_CR3
 .endm
 .macro SWITCH_USER_CR3
arch/x86/realmode/init.c +3 -1
index 0b7a63d98440..cfecb7d6c6a8 100644
@@ -1,5 +1,6 @@
 #include <linux/io.h>
 #include <linux/memblock.h>
+#include <linux/kaiser.h>
 
 #include <asm/cacheflush.h>
 #include <asm/pgtable.h>
@@ -15,7 +16,8 @@ void __init reserve_real_mode(void)
 	size_t size = PAGE_ALIGN(real_mode_blob_end - real_mode_blob);
 
 	/* Has to be under 1M so we can execute real-mode AP code. */
-	mem = memblock_find_in_range(0, 1<<20, size, PAGE_SIZE);
+	mem = memblock_find_in_range(0, 1 << 20, size,
+				     KAISER_KERNEL_PGD_ALIGNMENT);
 	if (!mem)
 		panic("Cannot allocate trampoline\n");
 
arch/x86/realmode/rm/trampoline_64.S +2 -1
index dac7b20d2f9d..781cca63f795 100644
@@ -30,6 +30,7 @@
 #include <asm/msr.h>
 #include <asm/segment.h>
 #include <asm/processor-flags.h>
+#include <asm/kaiser.h>
 #include "realmode.h"
 
 	.text
@@ -139,7 +140,7 @@ tr_gdt:
 tr_gdt_end:
 
 	.bss
-	.balign	PAGE_SIZE
+	.balign	KAISER_KERNEL_PGD_ALIGNMENT
 GLOBAL(trampoline_pgd)		.space	PAGE_SIZE
 
 	.balign	8
Signature · 1 line
1.8.3.1
#97 lore raw

If it is better to resubmit this patch via git send-email, please let me know.

Thank you,
Pavel

Quoted 8 lines · Pavel Tatashin

I have root caused the memory corruption panics/hangs that I've been experiencing during boot with the latest 4.4.110 kernel. The problem as was suspected by Andy Lutomirski is with interaction between PTI and EFI. It may affect any system that has EFI bios. I have not verified if it can affect any other kernel beside 4.4.110

Attached is the fix for this issue with explanations that Steve Sistare and I developed.

#98 lore raw

[ Patch to make sure the EFI trampoline_pgd is properly aligned and has the double pgd that KPTI requires ]

Quoted 1 line · Pavel Tatashin

If it is better to resubmit this patch via git send-email, please let me know.

It would be better, because that way the patch can be more easily quoted and discussed.

That said, I do not see why this isn't an issue upstream too.

As far as I can tell, it's not just 4.4.110. Our current entry code does that ADJUST_KERNEL_CR3 dance too, which clears the PTI_SWITCH_MASK bit from cr3.

And that realmode trampoline pgd seems all to be just aligned to PAGE_SIZE.

Now, in the modern world, we generate new page tables for EFI, but we still have that EFI_OLD_MEMMAP code that disables that. And afaik, EFI_OLD_MEMMAP has the exact same problem that your patch fixes in 4.4 (where it's always on).

So I think this patch should go into the development kernel too.

Or maybe it already is, and I just haven't gotten it yet.

Or - even more likely - I'm missing something entirely, and even EFI_OLD_MEMMAP solved this some other way upstream.

Adding Thomas Gleixner explicitly to the participants so that he can tell me I'm a moron and point me to the right thing.

Linus

#99 lore raw
Quoted 10 lines · Linus Torvalds

[ Patch to make sure the EFI trampoline_pgd is properly aligned and has the double pgd that KPTI requires ]

Quoted 1 line · Pavel Tatashin

If it is better to resubmit this patch via git send-email, please let me know.

It would be better, because that way the patch can be more easily quoted and discussed.

Quoted 7 lines

That said, I do not see why this isn't an issue upstream too.

As far as I can tell, it's not just 4.4.110. Our current entry code does that ADJUST_KERNEL_CR3 dance too, which clears the PTI_SWITCH_MASK bit from cr3.

And that realmode trampoline pgd seems all to be just aligned to PAGE_SIZE.

Right, but see below.

Quoted 8 lines

Now, in the modern world, we generate new page tables for EFI, but we still have that EFI_OLD_MEMMAP code that disables that. And afaik, EFI_OLD_MEMMAP has the exact same problem that your patch fixes in 4.4 (where it's always on).

So I think this patch should go into the development kernel too.

Or maybe it already is, and I just haven't gotten it yet.

It's not. There is an efi oldmap fix pending, but that's a different story.

Quoted 2 lines

Or - even more likely - I'm missing something entirely, and even EFI_OLD_MEMMAP solved this some other way upstream.

67a9108ed431 ("x86/efi: Build our own page table structures")

got rid of EFI depending on real_mode_header->trampoline_pgd

So I don't see how upstream needs the fix as the trampoline_pgd seems only to be used when coming out of the boot loader.

Adding Matt. He stepped back from EFI, but he might still know.

Quoted 2 lines

Adding Thomas Gleixner explicitly to the participants so that he can tell me I'm a moron and point me to the right thing.

Your wish is my command, but I need to stare some more before doing so.

Thanks,

tglx

#100 lore raw
Quoted 4 lines · Thomas Gleixner

67a9108ed431 ("x86/efi: Build our own page table structures")

got rid of EFI depending on real_mode_header->trampoline_pgd

So I think it only got rid of by default - the codepath is still there, the allocation is still there, it's just that it's not actually used unless somebody does that "efi=old_mmap" thing.

Looking around, there's at least one quirk for the SGI UV1 system that enables EFI_OLD_MMAP automatically. There might be others that I missed, but I think that's it.

So it *can* trigger without "efi=old_mmap", but not on any normal machines.

And as Pavel points out, even when the bug is active, it's pretty hard to actually trigger.

But yeah, there may be other EFI patches that I didn't notice that changed things in other ways too.

Linus

#101 lore raw
Quoted 9 lines · Linus Torvalds
Quoted 4 lines · Thomas Gleixner

67a9108ed431 ("x86/efi: Build our own page table structures")

got rid of EFI depending on real_mode_header->trampoline_pgd

So I think it only got rid of by default - the codepath is still there, the allocation is still there, it's just that it's not actually used unless somebody does that "efi=old_mmap" thing.

Yes, the trampoline_pgd is still around, but I can't figure out how it would be used after boot. Confused, digging more.

Thanks,

tglx

#102 lore raw
Quoted 6 lines · Thomas Gleixner
Quoted 4 lines · Linus Torvalds
Quoted 3 lines · Thomas Gleixner

67a9108ed431 ("x86/efi: Build our own page table structures")

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

got rid of EFI depending on real_mode_header->trampoline_pgd

So I think it only got rid of by default - the codepath is still there, the allocation is still there, it's just that it's not actually used unless somebody does that "efi=old_mmap" thing.

Yes, the trampoline_pgd is still around, but I can't figure out how it would be used after boot. Confused, digging more.

So coming back to the same commit. From the changelog:

This is caused by mapping EFI regions with RWX permissions. There isn't much we can do to restrict the permissions for these regions due to the way the firmware toolchains mix code and data, but we can at least isolate these mappings so that they do not appear in the regular kernel page tables.

In commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping") we started using 'trampoline_pgd' to map the EFI regions because there was an existing identity mapping there which we use during the SetVirtualAddressMap() call and for broken firmware that accesses those addresses.

So this very commit gets rid of the (ab)use of trampoline_pgd and allocates efi_pgd, which we made use the proper size.

trampoline_pgd is since then only used to get into long mode in realmode/rm/trampoline_64.S and for reboot in machine_real_restart().

The runtime services stuff does not use it in kernel versions >= 4.6

Thanks,

tglx

#103 lore raw
Quoted 33 lines · Thomas Gleixner
Quoted 6 lines · Thomas Gleixner
Quoted 4 lines · Linus Torvalds
Quoted 3 lines · Thomas Gleixner

67a9108ed431 ("x86/efi: Build our own page table structures")

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

got rid of EFI depending on real_mode_header->trampoline_pgd

So I think it only got rid of by default - the codepath is still there, the allocation is still there, it's just that it's not actually used unless somebody does that "efi=old_mmap" thing.

Yes, the trampoline_pgd is still around, but I can't figure out how it would be used after boot. Confused, digging more.

So coming back to the same commit. From the changelog:

This is caused by mapping EFI regions with RWX permissions. There isn't much we can do to restrict the permissions for these regions due to the way the firmware toolchains mix code and data, but we can at least isolate these mappings so that they do not appear in the regular kernel page tables.

In commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping") we started using 'trampoline_pgd' to map the EFI regions because there was an existing identity mapping there which we use during the SetVirtualAddressMap() call and for broken firmware that accesses those addresses.

So this very commit gets rid of the (ab)use of trampoline_pgd and allocates efi_pgd, which we made use the proper size.

Quoted 8 lines

trampoline_pgd is since then only used to get into long mode in realmode/rm/trampoline_64.S and for reboot in machine_real_restart().

The runtime services stuff does not use it in kernel versions >= 4.6

Thanks,

tglx

Yes, and addressing Linus' concern about EFI_OLD_MEMMAP, those paths are independent of it. When EFI_OLD_MMAP is enabled, the efi pgd is not used, and the bug will not bite.

- Steve

#104 lore raw
Quoted 39 lines · Steven Sistare
Quoted 38 lines · Thomas Gleixner
Quoted 6 lines · Thomas Gleixner
Quoted 4 lines · Linus Torvalds
Quoted 3 lines · Thomas Gleixner

67a9108ed431 ("x86/efi: Build our own page table structures")

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

got rid of EFI depending on real_mode_header->trampoline_pgd

So I think it only got rid of by default - the codepath is still there, the allocation is still there, it's just that it's not actually used unless somebody does that "efi=old_mmap" thing.

Yes, the trampoline_pgd is still around, but I can't figure out how it would be used after boot. Confused, digging more.

So coming back to the same commit. From the changelog:

This is caused by mapping EFI regions with RWX permissions. There isn't much we can do to restrict the permissions for these regions due to the way the firmware toolchains mix code and data, but we can at least isolate these mappings so that they do not appear in the regular kernel page tables.

In commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping") we started using 'trampoline_pgd' to map the EFI regions because there was an existing identity mapping there which we use during the SetVirtualAddressMap() call and for broken firmware that accesses those addresses.

So this very commit gets rid of the (ab)use of trampoline_pgd and allocates efi_pgd, which we made use the proper size.

trampoline_pgd is since then only used to get into long mode in realmode/rm/trampoline_64.S and for reboot in machine_real_restart().

The runtime services stuff does not use it in kernel versions >= 4.6

Quoted 7 lines
Quoted 3 lines

Thanks,

tglx

Yes, and addressing Linus' concern about EFI_OLD_MEMMAP, those paths are independent of it. When EFI_OLD_MMAP is enabled, the efi pgd is not used, and the bug will not bite.

We have a fix queued in tip/x86/pti which addresses a missing NX clear, but that's a different story.

Thanks,

tglx

#105 lore raw
Quoted 42 lines · Thomas Gleixner
Quoted 41 lines · Steven Sistare
Quoted 40 lines · Thomas Gleixner
Quoted 6 lines · Thomas Gleixner
Quoted 4 lines · Linus Torvalds
Quoted 3 lines · Thomas Gleixner

67a9108ed431 ("x86/efi: Build our own page table structures")

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

got rid of EFI depending on real_mode_header->trampoline_pgd

So I think it only got rid of by default - the codepath is still there, the allocation is still there, it's just that it's not actually used unless somebody does that "efi=old_mmap" thing.

Yes, the trampoline_pgd is still around, but I can't figure out how it would be used after boot. Confused, digging more.

So coming back to the same commit. From the changelog:

This is caused by mapping EFI regions with RWX permissions. There isn't much we can do to restrict the permissions for these regions due to the way the firmware toolchains mix code and data, but we can at least isolate these mappings so that they do not appear in the regular kernel page tables.

In commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping") we started using 'trampoline_pgd' to map the EFI regions because there was an existing identity mapping there which we use during the SetVirtualAddressMap() call and for broken firmware that accesses those addresses.

So this very commit gets rid of the (ab)use of trampoline_pgd and allocates efi_pgd, which we made use the proper size.

trampoline_pgd is since then only used to get into long mode in realmode/rm/trampoline_64.S and for reboot in machine_real_restart().

The runtime services stuff does not use it in kernel versions >= 4.6

Thanks,

Quoted 9 lines
Quoted 5 lines
Quoted 1 line

tglx

Yes, and addressing Linus' concern about EFI_OLD_MEMMAP, those paths are independent of it. When EFI_OLD_MMAP is enabled, the efi pgd is not used, and the bug will not bite.

We have a fix queued in tip/x86/pti which addresses a missing NX clear, but that's a different story.

Since you are talking about NX, I see this in last night's -next:

kernel tried to execute NX-protected page - exploit attempt? (uid: 0)

BUG: unable to handle kernel paging request at fffffe0000007000
IP: 0xfffffe0000006e9d
PGD ffd6067 P4D ffd6067 PUD ffd5067 PMD ff73067 PTE 800000000fc09063
Oops: 0011 [#1] PREEMPT SMP PTI
Modules linked in:
CPU: 0 PID: 1 Comm: init Tainted: G        W
4.15.0-rc7-next-20180111-yocto-standard #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
RIP: 0010:0xfffffe0000006e9d
RSP: 0018:ffffaee28000ffd0 EFLAGS: 00000006
RAX: 000000000000000c RBX: 0000000000400040 RCX: 00007f2c4186ad6a
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb6a00000
RBP: 0000000000000008 R08: 000000000000037f R09: 0000000000000064
R10: 00000000078bfbfd R11: 0000000000000246 R12: 00007f2c41856a60
R13: 0000000000000000 R14: 0000000000402368 R15: 0000000000001000
FS:  0000000000000000(0000) GS:ffff95fecfc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffe0000007000 CR3: 000000000d88a000 CR4: 00000000003406f0
Call Trace:
Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <90> 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 
RIP: 0xfffffe0000006e9d RSP: ffffaee28000ffd0
CR2: fffffe0000007000
---[ end trace a82b8742114c1785 ]---

Is this the issue you are talking about, or is the fix triggering the crash ?

Guenter

#106 lore raw
In reply to Steven Sistare
Quoted 4 lines · Steven Sistare

Yes, and addressing Linus' concern about EFI_OLD_MEMMAP, those paths are independent of it. When EFI_OLD_MMAP is enabled, the efi pgd is not used, and the bug will not bite.

Ok, good. Thanks for checking.

Linus

#107 lore raw
In reply to Thomas Gleixner
Quoted 30 lines · Thomas Gleixner
Quoted 6 lines · Thomas Gleixner
Quoted 4 lines · Linus Torvalds
Quoted 3 lines · Thomas Gleixner

67a9108ed431 ("x86/efi: Build our own page table structures")

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

got rid of EFI depending on real_mode_header->trampoline_pgd

So I think it only got rid of by default - the codepath is still there, the allocation is still there, it's just that it's not actually used unless somebody does that "efi=old_mmap" thing.

Yes, the trampoline_pgd is still around, but I can't figure out how it would be used after boot. Confused, digging more.

So coming back to the same commit. From the changelog:

This is caused by mapping EFI regions with RWX permissions. There isn't much we can do to restrict the permissions for these regions due to the way the firmware toolchains mix code and data, but we can at least isolate these mappings so that they do not appear in the regular kernel page tables.

In commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping") we started using 'trampoline_pgd' to map the EFI regions because there was an existing identity mapping there which we use during the SetVirtualAddressMap() call and for broken firmware that accesses those addresses.

Quoted 7 lines

So this very commit gets rid of the (ab)use of trampoline_pgd and allocates efi_pgd, which we made use the proper size.

trampoline_pgd is since then only used to get into long mode in realmode/rm/trampoline_64.S and for reboot in machine_real_restart().

The runtime services stuff does not use it in kernel versions >= 4.6

But there is one very well hidden user for it after boot:

It's used for booting secondary CPUs from real mode

So the transition to long mode for secondaries uses the trampoline pgd for long mode transition and then jumping to secondary_startup_64 where CR3 is set to the real kernel page tables.

Thanks,

tglx

author maintainer
#108 lore raw
Quoted 39 lines · Thomas Gleixner
Quoted 30 lines · Thomas Gleixner
Quoted 6 lines · Thomas Gleixner
Quoted 4 lines · Linus Torvalds
Quoted 3 lines · Thomas Gleixner

67a9108ed431 ("x86/efi: Build our own page table structures")

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

got rid of EFI depending on real_mode_header->trampoline_pgd

So I think it only got rid of by default - the codepath is still there, the allocation is still there, it's just that it's not actually used unless somebody does that "efi=old_mmap" thing.

Yes, the trampoline_pgd is still around, but I can't figure out how it would be used after boot. Confused, digging more.

So coming back to the same commit. From the changelog:

This is caused by mapping EFI regions with RWX permissions. There isn't much we can do to restrict the permissions for these regions due to the way the firmware toolchains mix code and data, but we can at least isolate these mappings so that they do not appear in the regular kernel page tables.

In commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping") we started using 'trampoline_pgd' to map the EFI regions because there was an existing identity mapping there which we use during the SetVirtualAddressMap() call and for broken firmware that accesses those addresses.

Quoted 7 lines

So this very commit gets rid of the (ab)use of trampoline_pgd and allocates efi_pgd, which we made use the proper size.

trampoline_pgd is since then only used to get into long mode in realmode/rm/trampoline_64.S and for reboot in machine_real_restart().

The runtime services stuff does not use it in kernel versions >= 4.6

Quoted 7 lines

But there is one very well hidden user for it after boot:

It's used for booting secondary CPUs from real mode

So the transition to long mode for secondaries uses the trampoline pgd for long mode transition and then jumping to secondary_startup_64 where CR3 is set to the real kernel page tables.

Ok, so the summary is that this patch is only needed for the 4.4 and 4.9 kernels, and _NOT_ for Linus's tree and 4.14, right?

thanks,

greg k-h

#109 lore raw
Quoted 7 lines · Greg Kroah-Hartman
Quoted 3 lines · Thomas Gleixner

So the transition to long mode for secondaries uses the trampoline pgd for long mode transition and then jumping to secondary_startup_64 where CR3 is set to the real kernel page tables.

Ok, so the summary is that this patch is only needed for the 4.4 and 4.9 kernels, and _NOT_ for Linus's tree and 4.14, right?

Correct.

#110 lore raw
In reply to Linus Torvalds
Quoted 16 lines · Linus Torvalds
Quoted 4 lines · Thomas Gleixner

67a9108ed431 ("x86/efi: Build our own page table structures")

got rid of EFI depending on real_mode_header->trampoline_pgd

So I think it only got rid of by default - the codepath is still there, the allocation is still there, it's just that it's not actually used unless somebody does that "efi=old_mmap" thing.

Looking around, there's at least one quirk for the SGI UV1 system that enables EFI_OLD_MMAP automatically. There might be others that I missed, but I think that's it.

So it *can* trigger without "efi=old_mmap", but not on any normal machines.

Quoted 7 lines

And as Pavel points out, even when the bug is active, it's pretty hard to actually trigger.

But yeah, there may be other EFI patches that I didn't notice that changed things in other ways too.

Linus

The bug is not present in the latest upstream kernel because the efi_pgd is correctly aligned:

  arch/x86/platform/efi/efi_64.c
    int __init efi_alloc_page_tables(void)
      efi_pgd = (pgd_t *)__get_free_pages(gfp_mask, PGD_ALLOCATION_ORDER);

arch/x86/include/asm/pgalloc.h
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
+#define PGD_ALLOCATION_ORDER 1
+#else
+#define PGD_ALLOCATION_ORDER 0
+#endif

Pavel's patch fixes kernels prior to
67a9108ed431 ("x86/efi: Build our own page table structures")

where the efi pgd allocation looks like:

  arch/x86/realmode/init.c
    void __init reserve_real_mode(void)
       mem = memblock_find_in_range(0, 1<<20, size, PAGE_SIZE);
       base = __va(mem);
       real_mode_header = (struct real_mode_header *) base;

  void __init setup_real_mode(void)
    trampoline_pgd = (u64 *) __va(real_mode_header->trampoline_pgd);

Kernel versions between 67a9108ed431 and the latest also have the bug and need a similar fix:

arch/x86/platform/efi/efi_64.c

    int __init efi_alloc_page_tables(void)
      efi_pgd = (pgd_t *)__get_free_page(gfp_mask);

    int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
      pgd = efi_pgd;
      efi_scratch.efi_pgt = (pgd_t *)__pa(efi_pgd);

All of the code paths above are taken when *not* EFI_OLD_MMAP.

- Steve

#111 lore raw
Quoted 23 lines · Steven Sistare
Quoted 22 lines · Linus Torvalds
Quoted 4 lines · Thomas Gleixner

67a9108ed431 ("x86/efi: Build our own page table structures")

got rid of EFI depending on real_mode_header->trampoline_pgd

So I think it only got rid of by default - the codepath is still there, the allocation is still there, it's just that it's not actually used unless somebody does that "efi=old_mmap" thing.

Looking around, there's at least one quirk for the SGI UV1 system that enables EFI_OLD_MMAP automatically. There might be others that I missed, but I think that's it.

So it *can* trigger without "efi=old_mmap", but not on any normal machines.

And as Pavel points out, even when the bug is active, it's pretty hard to actually trigger.

But yeah, there may be other EFI patches that I didn't notice that changed things in other ways too.

Quoted 8 lines
Quoted 1 line

Linus

The bug is not present in the latest upstream kernel because the efi_pgd is correctly aligned:

  arch/x86/platform/efi/efi_64.c
    int __init efi_alloc_page_tables(void)
      efi_pgd = (pgd_t *)__get_free_pages(gfp_mask, PGD_ALLOCATION_ORDER);

Yes, I came exactly to the same conclusion, but I didn't want to call Linus a moron before I triple checked that trampoline_pgd is still there, but only every used to get out of the realmode swamp at bpot.

Thanks,

tglx

#112 lore raw

On Jan 11, 2018 13:35, "Steven Sistare" <[email protected]> wrote:

All of the code paths above are taken when *not* EFI_OLD_MMAP.

But it is exactly the EFI_OLD_MMAP case I worry about.

Nobody should hopefully use it, but as mentioned, at least the SGI UV1 case enables it automatically.

And who knows how many users ended up adding it manually due to the problems we had for a while with EFI page tables (due to non-linear addresses when laying out the EFI data, but also due to bad EFI memory information from the BIOS)

Linus

author maintainer
#113 lore raw
In reply to Pavel Tatashin
Quoted 8 lines · Pavel Tatashin

I have root caused the memory corruption panics/hangs that I've been experiencing during boot with the latest 4.4.110 kernel. The problem as was suspected by Andy Lutomirski is with interaction between PTI and EFI. It may affect any system that has EFI bios. I have not verified if it can affect any other kernel beside 4.4.110

Attached is the fix for this issue with explanations that Steve Sistare and I developed.

Nice, but why does this not show up in 4.9 and 4.14 and Linus's tree as well on this hardware? Nor on the SLES12 SP3 kernel?

What is different there that 4.4 requires? That worries me more than your fix (which looks good to me, fwiw.)

thanks,

greg k-h

#114 lore raw
Quoted 6 lines · Greg Kroah-Hartman

Nice, but why does this not show up in 4.9 and 4.14 and Linus's tree as well on this hardware? Nor on the SLES12 SP3 kernel?

What is different there that 4.4 requires? That worries me more than your fix (which looks good to me, fwiw.)

I really think it's simply that since v4.6, we've had commit 67a9108ed431 ("x86/efi: Build our own page table structures"), so no normal EFI use actually uses the old legacy mapping unless you passed in "efi=old_map" on the kernel command line.

So the bug is there in all versions, it's just that it's normally only noticeable in 4.4.

But I might be missing some other difference, so take that with a pinch of salt.

Linus

#115 lore raw
In reply to Greg Kroah-Hartman
Quoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Pavel Tatashin

I have root caused the memory corruption panics/hangs that I've been experiencing during boot with the latest 4.4.110 kernel. The problem as was suspected by Andy Lutomirski is with interaction between PTI and EFI. It may affect any system that has EFI bios. I have not verified if it can affect any other kernel beside 4.4.110

Quoted 8 lines
Quoted 2 lines

Attached is the fix for this issue with explanations that Steve Sistare and I developed.

Nice, but why does this not show up in 4.9 and 4.14 and Linus's tree as well on this hardware? Nor on the SLES12 SP3 kernel?

What is different there that 4.4 requires? That worries me more than your fix (which looks good to me, fwiw.)

Hi Greg,

I have not studied other versions of kernels, efi was changed substantially since 4.4. But, even on 4.4.110 there are several things have to happen for this bug to show-up:

1. During boot memmblock must allocate address that is not 2PAGE_SIZE aligned.
2. nmi must arrive exactly when EFI replaced page table.

While I was debugging this problem, I tried to enable, kasan, vm_debug, add more printfs etc, but every little change would cause this problem to disappear, or appear less frequently.

Thank you,
Pavel

author maintainer
#116 lore raw
In reply to Andy Lutomirski
Quoted 21 lines · Andy Lutomirski
Quoted 5 lines · Greg Kroah-Hartman
Quoted 1 line · Pavel Tatashin

Boots successfully with "noefi" kernel parameter :)

Thanks, that will help me narrow it down. I'll dig through more patches when I get home tonight...

I wish you luck. The 4.4 series is "KAISER", not "KPTI", and the relevant code is spread all over the place and is generally garbage. See, for example, the turd called kaiser_set_shadow_pgd(). I would not be terribly surprised if that particular turd is biting here.

An alternative theory is that something is screwy in the EFI code. I don't see anything directly wrong, but it's certainly a bit sketchy. The newer kernels carefully avoid using PCID 0 for real work to avoid corruption due to EFI and similar things. The "KAISER" code has no such mitigation. Fortunately, it seems to use PCID=0 for kernel and PCID=nonzero for user, so the obvious problem isn't present, but something could still be wrong.

Quoted 5 lines

Pavel, can you send your /proc/cpuinfo on a noefi boot? (Just the first CPU worth is fine.)

FWIW, I said before that I have very little desire to help debug "KAISER". I stand by that.

I totally understand, and do not expect your help at all.

Worse case, I point people at 4.14 and tell them to upgrade, I'm not going to waste a ton of time on this for the same exact reasons you list here.

And yeah, kaiser_set_shadow_pgd() is horrid, I've already gotten sucked into it for long enough...

greg k-h

#117 lore raw
In reply to Andy Lutomirski
Quoted 20 lines · Andy Lutomirski
Quoted 20 lines · Linus Torvalds
Quoted 5 lines · Thomas Voegtle

Attached a screenshot.
Is that useful? Are there some debug options I can add?

Not much of an oops, because the SIGSEGV happens in user space. The only reason you get any kernel stack printout at all is because 'init' dying will make the kernel print that out.

The segfault address for init looks like the fixmap area to me (first byte in the last page of the fixmap?). "Error 5" means that it's a user-space read that got a protection fault. So it's not a LDT of GDT update or anything like that, it's a normal access from user space (or a qemu emulation bug, but that sounds unlikely).

Is that the vsyscall page?

Quoted 9 lines
Quoted 4 lines

Adding Luto to the participants. I think he noticed one of the vsyscall patches missing earlier in the 4.9 series. Maybe the 4.4 series had something similar..

That's almost certainly it.

I'll try to find some time today or tomorrow to add a proper selftest.

Give this a shot:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pti&id=17c5ebeb2e00879b0af1a9c32bf37ecdd9b9b31b

Boot with each of vsyscall=none, vsyscall=native, and vsyscall=emulate and run both the 32-bit and 64-bit variants of that test. All six combinations should pass. But I bet they don't on 4.4.

#118 lore raw
Quoted 31 lines · Andy Lutomirski
Quoted 20 lines · Andy Lutomirski
Quoted 20 lines · Linus Torvalds
Quoted 5 lines · Thomas Voegtle

Attached a screenshot.
Is that useful? Are there some debug options I can add?

Not much of an oops, because the SIGSEGV happens in user space. The only reason you get any kernel stack printout at all is because 'init' dying will make the kernel print that out.

The segfault address for init looks like the fixmap area to me (first byte in the last page of the fixmap?). "Error 5" means that it's a user-space read that got a protection fault. So it's not a LDT of GDT update or anything like that, it's a normal access from user space (or a qemu emulation bug, but that sounds unlikely).

Is that the vsyscall page?

Quoted 9 lines
Quoted 4 lines

Adding Luto to the participants. I think he noticed one of the vsyscall patches missing earlier in the 4.9 series. Maybe the 4.4 series had something similar..

That's almost certainly it.

I'll try to find some time today or tomorrow to add a proper selftest.

Quoted 7 lines

Give this a shot:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pti&id=17c5ebeb2e00879b0af1a9c32bf37ecdd9b9b31b

Boot with each of vsyscall=none, vsyscall=native, and vsyscall=emulate and run both the 32-bit and 64-bit variants of that test. All six combinations should pass. But I bet they don't on 4.4.

With my 4.4.110-rc1 under QEMU -cpu=host (Xeon E5-2690 v3)

vsyscall=emulate:

# ./test_vsyscall_64
...
[RUN]   Checking read access to the vsyscall page
[FAIL]  We don't have read access, but we should

vsyscall=native:

# ./test_vsyscall_64
...
[RUN]   Checking read access to the vsyscall page
[FAIL]  We don't have read access, but we should

Everything else passes.

Note that test_vsyscall_32 warns:

# ./test_vsyscall_32
Warning: failed to find getcpu in vDSO
...

-Kees

Signature · 2 lines
Kees Cook
Pixel Security
author maintainer
#119 lore raw
Quoted 5 lines · Kees Cook

Note that test_vsyscall_32 warns:

# ./test_vsyscall_32
Warning: failed to find getcpu in vDSO
...

It gives me that warning with 4.15-rc6 as well.

thanks,

greg k-h

author maintainer
#120 lore raw
In reply to Kees Cook
Quoted 49 lines · Kees Cook
Quoted 31 lines · Andy Lutomirski
Quoted 20 lines · Andy Lutomirski
Quoted 20 lines · Linus Torvalds
Quoted 5 lines · Thomas Voegtle

Attached a screenshot.
Is that useful? Are there some debug options I can add?

Not much of an oops, because the SIGSEGV happens in user space. The only reason you get any kernel stack printout at all is because 'init' dying will make the kernel print that out.

The segfault address for init looks like the fixmap area to me (first byte in the last page of the fixmap?). "Error 5" means that it's a user-space read that got a protection fault. So it's not a LDT of GDT update or anything like that, it's a normal access from user space (or a qemu emulation bug, but that sounds unlikely).

Is that the vsyscall page?

Quoted 9 lines
Quoted 4 lines

Adding Luto to the participants. I think he noticed one of the vsyscall patches missing earlier in the 4.9 series. Maybe the 4.4 series had something similar..

That's almost certainly it.

I'll try to find some time today or tomorrow to add a proper selftest.

Quoted 7 lines

Give this a shot:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pti&id=17c5ebeb2e00879b0af1a9c32bf37ecdd9b9b31b

Boot with each of vsyscall=none, vsyscall=native, and vsyscall=emulate and run both the 32-bit and 64-bit variants of that test. All six combinations should pass. But I bet they don't on 4.4.

With my 4.4.110-rc1 under QEMU -cpu=host (Xeon E5-2690 v3)

vsyscall=emulate:

# ./test_vsyscall_64
...
[RUN]   Checking read access to the vsyscall page
[FAIL]  We don't have read access, but we should
Quoted 8 lines

vsyscall=native:

# ./test_vsyscall_64
...
[RUN]   Checking read access to the vsyscall page
[FAIL]  We don't have read access, but we should

Everything else passes.

I get this same error with the latest 4.9-rc tree as well, but it works just fine on 4.15-rc6.

I'll look at the proposed patches now for this...

thanks so much for the test tool.

greg k-h

#121 lore raw
In reply to Thomas Voegtle
Quoted 13 lines · Thomas Voegtle

When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a segfault and the kernel panics (attempted to kill init). The VM host is a Haswell system.

The same kernel binary boots fine on a (other) Haswell system.

I tried:

4.4.110-rc1     broken
4.4.109         ok
4.9.75-rc1      ok
Quoted 9 lines

All systems are OpenSuSE 42.3 64bit.

qemu is started only with:
qemu-system-x86_64 -m 2048 -enable-kvm -drive file=tvsuse,format=raw,if=none,id=virtdisk0 -device virtio-blk-pci,scsi=off,drive=virtdisk0

Am I the only one who sees this? Has anyone booted that kernel on qemu?

I did, but not on Haswell, and not with the same root file system. It boots fine in qemu on E5-2690 v3.

Do you have a traceback ?

Guenter

Quoted 4 lines

Confused,

Thomas

author maintainer
#122 lore raw
In reply to Thomas Voegtle
Quoted 13 lines · Thomas Voegtle

When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a segfault and the kernel panics (attempted to kill init). The VM host is a Haswell system.

The same kernel binary boots fine on a (other) Haswell system.

I tried:

4.4.110-rc1     broken
4.4.109         ok
4.9.75-rc1      ok
Quoted 8 lines

All systems are OpenSuSE 42.3 64bit.

qemu is started only with:
qemu-system-x86_64 -m 2048 -enable-kvm -drive file=tvsuse,format=raw,if=none,id=virtdisk0 -device virtio-blk-pci,scsi=off,drive=virtdisk0

Am I the only one who sees this? Has anyone booted that kernel on qemu?

I've now released 4.4.110, which had 4 more patches on top of what 4.4.109-rc1 had in it, that should hopefully resolve these issues.

Can you test that and let me know if you still have problems?

thanks,

greg k-h

#123 lore raw
Quoted 21 lines · Greg Kroah-Hartman
Quoted 20 lines · Thomas Voegtle

When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a segfault and the kernel panics (attempted to kill init). The VM host is a Haswell system.

The same kernel binary boots fine on a (other) Haswell system.

I tried:

4.4.110-rc1     broken
4.4.109         ok
4.9.75-rc1      ok

All systems are OpenSuSE 42.3 64bit.

qemu is started only with:
qemu-system-x86_64 -m 2048 -enable-kvm -drive file=tvsuse,format=raw,if=none,id=virtdisk0 -device virtio-blk-pci,scsi=off,drive=virtdisk0

Quoted 6 lines
Quoted 1 line

Am I the only one who sees this? Has anyone booted that kernel on qemu?

I've now released 4.4.110, which had 4 more patches on top of what 4.4.109-rc1 had in it, that should hopefully resolve these issues.

Can you test that and let me know if you still have problems?

It's fixed. I can boot 4.4.110 on qemu without problems so far.

./test_vsyscall_64 still fails though, like Kees wrote about 4.4.110-rc1
https://lkml.org/lkml/2018/1/5/123

That's another issue?

Thank you very much.

Thomas

author maintainer
#124 lore raw
Quoted 23 lines · Thomas Voegtle
Quoted 21 lines · Greg Kroah-Hartman
Quoted 20 lines · Thomas Voegtle

When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a segfault and the kernel panics (attempted to kill init). The VM host is a Haswell system.

The same kernel binary boots fine on a (other) Haswell system.

I tried:

4.4.110-rc1     broken
4.4.109         ok
4.9.75-rc1      ok

All systems are OpenSuSE 42.3 64bit.

qemu is started only with:
qemu-system-x86_64 -m 2048 -enable-kvm -drive file=tvsuse,format=raw,if=none,id=virtdisk0 -device virtio-blk-pci,scsi=off,drive=virtdisk0

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

Am I the only one who sees this? Has anyone booted that kernel on qemu?

I've now released 4.4.110, which had 4 more patches on top of what 4.4.109-rc1 had in it, that should hopefully resolve these issues.

Can you test that and let me know if you still have problems?

It's fixed. I can boot 4.4.110 on qemu without problems so far.

Yeah!!!

Quoted 4 lines

./test_vsyscall_64 still fails though, like Kees wrote about 4.4.110-rc1
https://lkml.org/lkml/2018/1/5/123

That's another issue?

Yes it is, that's next up to get resolved.

thanks for testing and letting me know,

greg k-h

#125 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.110-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

Based on the email threads, I expected to see issues, however, compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

author maintainer
#126 lore raw
Quoted 15 lines · Shuah Khan
Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.110-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

Quoted 7 lines
Quoted 4 lines

thanks,

greg k-h

Based on the email threads, I expected to see issues, however, compiled and booted on my test system. No dmesg regressions.

Hey, you got lucky :)

Thanks for testing all of these and letting me know.

greg k-h

#127 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

This is also reported to crash if loaded under qemu + haxm under windows. See https://www.spinics.net/lists/kernel/msg2689835.html for details. Here is a boot log (the log is from chromeos-4.4, but Tao Wu says that the same log is also seen with vanilla v4.4.110-rc1).

[    0.712750] Freeing unused kernel memory: 552K
[    0.721821] init: Corrupted page table at address 57b029b332e0
[    0.722761] PGD 80000000bb238067 PUD bc36a067 PMD bc369067 PTE 45d2067
[    0.722761] Bad pagetable: 000b [#1] PREEMPT SMP 
[    0.722761] Modules linked in:
[    0.722761] CPU: 1 PID: 1 Comm: init Not tainted 4.4.96 #31
[    0.722761] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
[    0.722761] task: ffff8800bc290000 ti: ffff8800bc28c000 task.ti: ffff8800bc28c000
[    0.722761] RIP: 0010:[<ffffffff83f4129e>]  [<ffffffff83f4129e>] __clear_user+0x42/0x67
[    0.722761] RSP: 0000:ffff8800bc28fcf8  EFLAGS: 00010202
[    0.722761] RAX: 0000000000000000 RBX: 00000000000001a4 RCX: 00000000000001a4
[    0.722761] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000057b029b332e0
[    0.722761] RBP: ffff8800bc28fd08 R08: ffff8800bc290000 R09: ffff8800bb2f4000
[    0.722761] R10: ffff8800bc290000 R11: ffff8800bb2f4000 R12: 000057b029b332e0
[    0.722761] R13: 0000000000000000 R14: 000057b029b33340 R15: ffff8800bb1e2a00
[    0.722761] FS:  0000000000000000(0000) GS:ffff8800bfb00000(0000) knlGS:0000000000000000
[    0.722761] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[    0.722761] CR2: 000057b029b332e0 CR3: 00000000bb2f8000 CR4: 00000000000006e0
[    0.722761] Stack:
[    0.722761]  000057b029b332e0 ffff8800bb95fa80 ffff8800bc28fd18 ffffffff83f4120c
[    0.722761]  ffff8800bc28fe18 ffffffff83e9e7a1 ffff8800bc28fd68 0000000000000000
[    0.722761]  ffff8800bc290000 ffff8800bc290000 ffff8800bc290000 ffff8800bc290000
[    0.722761] Call Trace:
[    0.722761]  [<ffffffff83f4120c>] clear_user+0x2e/0x30
[    0.722761]  [<ffffffff83e9e7a1>] load_elf_binary+0xa7f/0x18f7
[    0.722761]  [<ffffffff83de2088>] search_binary_handler+0x86/0x19c
[    0.722761]  [<ffffffff83de389e>] do_execveat_common.isra.26+0x909/0xf98
[    0.722761]  [<ffffffff844febe0>] ? rest_init+0x87/0x87
[    0.722761]  [<ffffffff83de40be>] do_execve+0x23/0x25
[    0.722761]  [<ffffffff83c002e3>] run_init_process+0x2b/0x2d
[    0.722761]  [<ffffffff844fec4d>] kernel_init+0x6d/0xda
[    0.722761]  [<ffffffff84505b2f>] ret_from_fork+0x3f/0x70
[    0.722761]  [<ffffffff844febe0>] ? rest_init+0x87/0x87
[    0.722761] Code: 86 84 be 12 00 00 00 e8 87 0d e8 ff 66 66 90 48 89 d8 48 c1
eb 03 4c 89 e7 83 e0 07 48 89 d9 be 08 00 00 00 31 d2 48 85 c9 74 0a <48> 89 17
48 01 f7 ff c9 75 f6 48 89 c1 85 c9 74 09 88 17 48 ff 
[    0.722761] RIP  [<ffffffff83f4129e>] __clear_user+0x42/0x67
[    0.722761]  RSP <ffff8800bc28fcf8>
[    0.722761] ---[ end trace def703879b4ff090 ]---
[    0.722761] BUG: sleeping function called from invalid context at /mnt/host/source/src/third_party/kernel/v4.4/kernel/locking/rwsem.c:21
[    0.722761] in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: init
[    0.722761] CPU: 1 PID: 1 Comm: init Tainted: G      D         4.4.96 #31
[    0.722761] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
[    0.722761]  0000000000000086 dcb5d76098c89836 ffff8800bc28fa30 ffffffff83f34004
[    0.722761]  ffffffff84839dc2 0000000000000015 ffff8800bc28fa40 ffffffff83d57dc9
[    0.722761]  ffff8800bc28fa68 ffffffff83d57e6a ffffffff84a53640 0000000000000000
[    0.722761] Call Trace:
[    0.722761]  [<ffffffff83f34004>] dump_stack+0x4d/0x63
[    0.722761]  [<ffffffff83d57dc9>] ___might_sleep+0x13a/0x13c
[    0.722761]  [<ffffffff83d57e6a>] __might_sleep+0x9f/0xa6
[    0.722761]  [<ffffffff84502788>] down_read+0x20/0x31
[    0.722761]  [<ffffffff83cc5d9b>] __blocking_notifier_call_chain+0x35/0x63
[    0.722761]  [<ffffffff83cc5ddd>] blocking_notifier_call_chain+0x14/0x16
[    0.800374] usb 1-1: new full-speed USB device number 2 using uhci_hcd
[    0.722761]  [<ffffffff83cefe97>] profile_task_exit+0x1a/0x1c
[    0.802309]  [<ffffffff83cac84e>] do_exit+0x39/0xe7f
[    0.802309]  [<ffffffff83ce5938>] ? vprintk_default+0x1d/0x1f
[    0.802309]  [<ffffffff83d7bb95>] ? printk+0x57/0x73
[    0.802309]  [<ffffffff83c46e25>] oops_end+0x80/0x85
[    0.802309]  [<ffffffff83c7b747>] pgtable_bad+0x8a/0x95
[    0.802309]  [<ffffffff83ca7f4a>] __do_page_fault+0x8c/0x352
[    0.802309]  [<ffffffff83eefba5>] ? file_has_perm+0xc4/0xe5
[    0.802309]  [<ffffffff83ca821c>] do_page_fault+0xc/0xe
[    0.802309]  [<ffffffff84507682>] page_fault+0x22/0x30
[    0.802309]  [<ffffffff83f4129e>] ? __clear_user+0x42/0x67
[    0.802309]  [<ffffffff83f4127f>] ? __clear_user+0x23/0x67
[    0.802309]  [<ffffffff83f4120c>] clear_user+0x2e/0x30
[    0.802309]  [<ffffffff83e9e7a1>] load_elf_binary+0xa7f/0x18f7
[    0.802309]  [<ffffffff83de2088>] search_binary_handler+0x86/0x19c
[    0.802309]  [<ffffffff83de389e>] do_execveat_common.isra.26+0x909/0xf98
[    0.802309]  [<ffffffff844febe0>] ? rest_init+0x87/0x87
[    0.802309]  [<ffffffff83de40be>] do_execve+0x23/0x25
[    0.802309]  [<ffffffff83c002e3>] run_init_process+0x2b/0x2d
[    0.802309]  [<ffffffff844fec4d>] kernel_init+0x6d/0xda
[    0.802309]  [<ffffffff84505b2f>] ret_from_fork+0x3f/0x70
[    0.802309]  [<ffffffff844febe0>] ? rest_init+0x87/0x87
[    0.830559] Kernel panic - not syncing: Attempted to kill init!  exitcode=0x00000009
[    0.830559] 
[    0.831305] Kernel Offset: 0x2c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    0.831305] ---[ end Kernel panic - not syncing: Attempted to kill init!  exitcode=0x00000009

The crash part of this problem may be solved with the following patch (thanks to Hugh for the hint). There is still another problem, though - with this patch applied, the qemu session aborts with "VCPU Shutdown request", whatever that means.

Guenter

---
From: Guenter Roeck <[email protected]>
Date: Thu, 4 Jan 2018 13:41:55 -0800
Subject: [PATCH 2/2] WIP: kaiser: Set _PAGE_NX only if supported

Change-Id Ie6ab566c1d725b24c4b3aa80a47c3ff3a5feddb9
---
 arch/x86/mm/kaiser.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
arch/x86/mm/kaiser.c +2 -1
index 7d2f7eb6857f..e4706273d4a1 100644
@@ -421,7 +421,8 @@ pgd_t kaiser_set_shadow_pgd(pgd_t *pgdp, pgd_t pgd)
 			 * get out to userspace running on the kernel CR3,
 			 * userspace will crash instead of running.
 			 */
-			pgd.pgd |= _PAGE_NX;
+			if (__supported_pte_mask & _PAGE_NX)
+				pgd.pgd |= _PAGE_NX;
 		}
 	} else if (!pgd.pgd) {
 		/*
Signature · 1 line
2.16.0.rc0.223.g4a4ac83678-goog
#128 lore raw
Quoted 4 lines · Guenter Roeck
[    0.721821] init: Corrupted page table at address 57b029b332e0
[    0.722761] PGD 80000000bb238067 PUD bc36a067 PMD bc369067 PTE 45d2067
[    0.722761] Bad pagetable: 000b [#1] PREEMPT SMP

Ok, it's unhappy because the RSVD bit is set in the error code.

And yeah, that seems to be due to NX in the pgd (nothing else is certainly set), with presumably a virtual machine that doesn't support it.

So I suspect your patch is indeed the right thing.

Quoted 4 lines

The crash part of this problem may be solved with the following patch (thanks to Hugh for the hint). There is still another problem, though - with this patch applied, the qemu session aborts with "VCPU Shutdown request", whatever that means.

Presumably that is a triple fault.

That causes a reboot traditionally, and in a virtual environment that would be approximated with a VCPU shutdown.

Linus

#129 lore raw
In reply to Guenter Roeck
Quoted 5 lines · Guenter Roeck

The crash part of this problem may be solved with the following patch (thanks to Hugh for the hint). There is still another problem, though - with this patch applied, the qemu session aborts with "VCPU Shutdown request", whatever that means.

The crash part is not fixed by your patch here, w/wo I get this, and it is PTI, as virgin 109 boots/works with identical everything else. ᅵMy shiny new PTI equipped enterprise 4.4 RT kernels also boot/work fine, which seems a bit odd.. and not particularly comforting.

[    1.244354] Freeing unused kernel memory: 1192K
[    1.245278] Write protecting the kernel read-only data: 10240k
[    1.247626] Freeing unused kernel memory: 1152K
[    1.251318] Freeing unused kernel memory: 1476K
[    1.253393] init[1]: segfault at ffffffffff5ff100 ip 00007fffb7ffac6e sp 00007fffb7fa07d8 error 5
[    1.254629] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    1.254629] 
[    1.256202] CPU: 4 PID: 1 Comm: init Not tainted 4.4.110-rc1-smp #4
[    1.257169] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
[    1.258563]  0000000000000000 ffffffff8125a9c0 ffffffff817de7c8 ffff880197e83cf0
[    1.260850]  ffffffff8112bb2d ffffffff00000010 ffff880197e83d00 ffff880197e83ca0
[    1.263091]  ffffffff81c3cf30 000000000000000b ffff880197e90010 0000000000000000
[    1.264580] Call Trace:
[    1.265617]  [<ffffffff8125a9c0>] ? dump_stack+0x5c/0x7c
[    1.266671]  [<ffffffff8112bb2d>] ? panic+0xc8/0x20f
[    1.267799]  [<ffffffff81060af0>] ? do_exit+0xa50/0xa50
[    1.268971]  [<ffffffff810618e9>] ? do_group_exit+0x39/0xa0
[    1.270281]  [<ffffffff8106c8a0>] ? get_signal+0x1d0/0x600
[    1.271347]  [<ffffffff810041e3>] ? do_signal+0x23/0x5b0
[    1.272259]  [<ffffffff8106ade9>] ? __send_signal+0x179/0x460
[    1.273235]  [<ffffffff8104b88f>] ? force_sig_info_fault+0x5f/0x70
[    1.274258]  [<ffffffff8104bf6c>] ? __bad_area_nosemaphore+0x1cc/0x200
[    1.275268]  [<ffffffff8105a052>] ? exit_to_usermode_loop+0x54/0x95
[    1.276262]  [<ffffffff81001961>] ? prepare_exit_to_usermode+0x31/0x40
[    1.277266]  [<ffffffff814d9dbe>] ? retint_user+0x8/0x2c
[    1.278274] Dumping ftrace buffer:
[    1.279011]    (ftrace buffer empty)
[    1.279728] Kernel Offset: disabled
[    1.280432] Rebooting in 60 seconds..

virsh # exit
ᅵ

Quoted 28 lines

Guenter

---
From: Guenter Roeck <[email protected]>
Date: Thu, 4 Jan 2018 13:41:55 -0800
Subject: [PATCH 2/2] WIP: kaiser: Set _PAGE_NX only if supported

Change-Id Ie6ab566c1d725b24c4b3aa80a47c3ff3a5feddb9
---
 arch/x86/mm/kaiser.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
arch/x86/mm/kaiser.c +2 -1
index 7d2f7eb6857f..e4706273d4a1 100644
@@ -421,7 +421,8 @@ pgd_t kaiser_set_shadow_pgd(pgd_t *pgdp, pgd_t pgd)
 			 * get out to userspace running on the kernel CR3,
 			 * userspace will crash instead of running.
 			 */
-			pgd.pgd |= _PAGE_NX;
+			if (__supported_pte_mask & _PAGE_NX)
+				pgd.pgd |= _PAGE_NX;
 		}
 	} else if (!pgd.pgd) {
 		/*
author maintainer
#130 lore raw
Quoted 11 lines · Mike Galbraith
Quoted 5 lines · Guenter Roeck

The crash part of this problem may be solved with the following patch (thanks to Hugh for the hint). There is still another problem, though - with this patch applied, the qemu session aborts with "VCPU Shutdown request", whatever that means.

The crash part is not fixed by your patch here, w/wo I get this, and it is PTI, as virgin 109 boots/works with identical everything else. �My shiny new PTI equipped enterprise 4.4 RT kernels also boot/work fine, which seems a bit odd.. and not particularly comforting.

Might I ask _what_ enterprise 4.4 kernels you are trying here? This should be the identical set to what is in the SLES12 tree, which worries me a lot...

thanks,

greg k-h

#131 lore raw
Quoted 8 lines · Greg Kroah-Hartman
Quoted 7 lines · Mike Galbraith
Quoted 5 lines · Guenter Roeck

The crash part of this problem may be solved with the following patch (thanks to Hugh for the hint). There is still another problem, though - with this patch applied, the qemu session aborts with "VCPU Shutdown request", whatever that means.

Quoted 8 lines
Quoted 4 lines

The crash part is not fixed by your patch here, w/wo I get this, and it is PTI, as virgin 109 boots/works with identical everything else. ᅵMy shiny new PTI equipped enterprise 4.4 RT kernels also boot/work fine, which seems a bit odd.. and not particularly comforting.

Might I ask _what_ enterprise 4.4 kernels you are trying here? This should be the identical set to what is in the SLES12 tree, which worries me a lot...

SLE12-SP[23]-RT, currently 4.4.104 based. Parent trees boot fine in the vm too. I thought perhaps it was a config difference, but seems not, 4.4.110-rc1 built with as close to enterprise config as you can get blows up the same as my light config.

-Mike

author maintainer
#132 lore raw
Quoted 14 lines · Mike Galbraith
Quoted 13 lines · Greg Kroah-Hartman
Quoted 11 lines · Mike Galbraith
Quoted 5 lines · Guenter Roeck

The crash part of this problem may be solved with the following patch (thanks to Hugh for the hint). There is still another problem, though - with this patch applied, the qemu session aborts with "VCPU Shutdown request", whatever that means.

The crash part is not fixed by your patch here, w/wo I get this, and it is PTI, as virgin 109 boots/works with identical everything else. �My shiny new PTI equipped enterprise 4.4 RT kernels also boot/work fine, which seems a bit odd.. and not particularly comforting.

Quoted 8 lines
Quoted 3 lines

Might I ask _what_ enterprise 4.4 kernels you are trying here? This should be the identical set to what is in the SLES12 tree, which worries me a lot...

SLE12-SP[23]-RT, currently 4.4.104 based. Parent trees boot fine in the vm too. I thought perhaps it was a config difference, but seems not, 4.4.110-rc1 built with as close to enterprise config as you can get blows up the same as my light config.

Ok, we found two patches that were missing in 4.4-stable that were in the SLES12 tree (thanks to Jamie Iles), now I only have 19k more to sift through :)

I should probably do an "interm" release to get people to be able to sync up to a common place easier for testing, dealing with patch sets and random emails saying different git ids is not easy for anyone.

thanks,

greg k-h

#133 lore raw
Quoted 4 lines · Greg Kroah-Hartman

Ok, we found two patches that were missing in 4.4-stable that were in the SLES12 tree (thanks to Jamie Iles), now I only have 19k more to sift through :)

As you know, in enterprise, uname -r means you might find something this old in your kernel if you look hard enough :)

-Mike

#134 lore raw
Quoted 8 lines · Mike Galbraith
Quoted 4 lines · Greg Kroah-Hartman

Ok, we found two patches that were missing in 4.4-stable that were in the SLES12 tree (thanks to Jamie Iles), now I only have 19k more to sift through :)

As you know, in enterprise, uname -r means you might find something this old in your kernel if you look hard enough :)

Mike, I think there's a good chance that Greg's 4.4.110 final will fix your "segfault at ffffffffff5ff100" crashes: please give it a try when you can, and let us know - thanks.

Hugh

#135 lore raw
Quoted 7 lines · Hugh Dickins
Quoted 6 lines · Mike Galbraith
Quoted 4 lines · Greg Kroah-Hartman

Ok, we found two patches that were missing in 4.4-stable that were in the SLES12 tree (thanks to Jamie Iles), now I only have 19k more to sift through :)

Quoted 6 lines
Quoted 2 lines

As you know, in enterprise, uname -r means you might find something this old in your kernel if you look hard enough :)

Mike, I think there's a good chance that Greg's 4.4.110 final will fix your "segfault at ffffffffff5ff100" crashes: please give it a try when you can, and let us know - thanks.

Already done, and yes, it did.

-Mike

author maintainer
#136 lore raw
In reply to Guenter Roeck
Quoted 120 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

This is also reported to crash if loaded under qemu + haxm under windows. See https://www.spinics.net/lists/kernel/msg2689835.html for details. Here is a boot log (the log is from chromeos-4.4, but Tao Wu says that the same log is also seen with vanilla v4.4.110-rc1).

[    0.712750] Freeing unused kernel memory: 552K
[    0.721821] init: Corrupted page table at address 57b029b332e0
[    0.722761] PGD 80000000bb238067 PUD bc36a067 PMD bc369067 PTE 45d2067
[    0.722761] Bad pagetable: 000b [#1] PREEMPT SMP 
[    0.722761] Modules linked in:
[    0.722761] CPU: 1 PID: 1 Comm: init Not tainted 4.4.96 #31
[    0.722761] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
[    0.722761] task: ffff8800bc290000 ti: ffff8800bc28c000 task.ti: ffff8800bc28c000
[    0.722761] RIP: 0010:[<ffffffff83f4129e>]  [<ffffffff83f4129e>] __clear_user+0x42/0x67
[    0.722761] RSP: 0000:ffff8800bc28fcf8  EFLAGS: 00010202
[    0.722761] RAX: 0000000000000000 RBX: 00000000000001a4 RCX: 00000000000001a4
[    0.722761] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000057b029b332e0
[    0.722761] RBP: ffff8800bc28fd08 R08: ffff8800bc290000 R09: ffff8800bb2f4000
[    0.722761] R10: ffff8800bc290000 R11: ffff8800bb2f4000 R12: 000057b029b332e0
[    0.722761] R13: 0000000000000000 R14: 000057b029b33340 R15: ffff8800bb1e2a00
[    0.722761] FS:  0000000000000000(0000) GS:ffff8800bfb00000(0000) knlGS:0000000000000000
[    0.722761] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[    0.722761] CR2: 000057b029b332e0 CR3: 00000000bb2f8000 CR4: 00000000000006e0
[    0.722761] Stack:
[    0.722761]  000057b029b332e0 ffff8800bb95fa80 ffff8800bc28fd18 ffffffff83f4120c
[    0.722761]  ffff8800bc28fe18 ffffffff83e9e7a1 ffff8800bc28fd68 0000000000000000
[    0.722761]  ffff8800bc290000 ffff8800bc290000 ffff8800bc290000 ffff8800bc290000
[    0.722761] Call Trace:
[    0.722761]  [<ffffffff83f4120c>] clear_user+0x2e/0x30
[    0.722761]  [<ffffffff83e9e7a1>] load_elf_binary+0xa7f/0x18f7
[    0.722761]  [<ffffffff83de2088>] search_binary_handler+0x86/0x19c
[    0.722761]  [<ffffffff83de389e>] do_execveat_common.isra.26+0x909/0xf98
[    0.722761]  [<ffffffff844febe0>] ? rest_init+0x87/0x87
[    0.722761]  [<ffffffff83de40be>] do_execve+0x23/0x25
[    0.722761]  [<ffffffff83c002e3>] run_init_process+0x2b/0x2d
[    0.722761]  [<ffffffff844fec4d>] kernel_init+0x6d/0xda
[    0.722761]  [<ffffffff84505b2f>] ret_from_fork+0x3f/0x70
[    0.722761]  [<ffffffff844febe0>] ? rest_init+0x87/0x87
[    0.722761] Code: 86 84 be 12 00 00 00 e8 87 0d e8 ff 66 66 90 48 89 d8 48 c1
eb 03 4c 89 e7 83 e0 07 48 89 d9 be 08 00 00 00 31 d2 48 85 c9 74 0a <48> 89 17
48 01 f7 ff c9 75 f6 48 89 c1 85 c9 74 09 88 17 48 ff 
[    0.722761] RIP  [<ffffffff83f4129e>] __clear_user+0x42/0x67
[    0.722761]  RSP <ffff8800bc28fcf8>
[    0.722761] ---[ end trace def703879b4ff090 ]---
[    0.722761] BUG: sleeping function called from invalid context at /mnt/host/source/src/third_party/kernel/v4.4/kernel/locking/rwsem.c:21
[    0.722761] in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: init
[    0.722761] CPU: 1 PID: 1 Comm: init Tainted: G      D         4.4.96 #31
[    0.722761] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
[    0.722761]  0000000000000086 dcb5d76098c89836 ffff8800bc28fa30 ffffffff83f34004
[    0.722761]  ffffffff84839dc2 0000000000000015 ffff8800bc28fa40 ffffffff83d57dc9
[    0.722761]  ffff8800bc28fa68 ffffffff83d57e6a ffffffff84a53640 0000000000000000
[    0.722761] Call Trace:
[    0.722761]  [<ffffffff83f34004>] dump_stack+0x4d/0x63
[    0.722761]  [<ffffffff83d57dc9>] ___might_sleep+0x13a/0x13c
[    0.722761]  [<ffffffff83d57e6a>] __might_sleep+0x9f/0xa6
[    0.722761]  [<ffffffff84502788>] down_read+0x20/0x31
[    0.722761]  [<ffffffff83cc5d9b>] __blocking_notifier_call_chain+0x35/0x63
[    0.722761]  [<ffffffff83cc5ddd>] blocking_notifier_call_chain+0x14/0x16
[    0.800374] usb 1-1: new full-speed USB device number 2 using uhci_hcd
[    0.722761]  [<ffffffff83cefe97>] profile_task_exit+0x1a/0x1c
[    0.802309]  [<ffffffff83cac84e>] do_exit+0x39/0xe7f
[    0.802309]  [<ffffffff83ce5938>] ? vprintk_default+0x1d/0x1f
[    0.802309]  [<ffffffff83d7bb95>] ? printk+0x57/0x73
[    0.802309]  [<ffffffff83c46e25>] oops_end+0x80/0x85
[    0.802309]  [<ffffffff83c7b747>] pgtable_bad+0x8a/0x95
[    0.802309]  [<ffffffff83ca7f4a>] __do_page_fault+0x8c/0x352
[    0.802309]  [<ffffffff83eefba5>] ? file_has_perm+0xc4/0xe5
[    0.802309]  [<ffffffff83ca821c>] do_page_fault+0xc/0xe
[    0.802309]  [<ffffffff84507682>] page_fault+0x22/0x30
[    0.802309]  [<ffffffff83f4129e>] ? __clear_user+0x42/0x67
[    0.802309]  [<ffffffff83f4127f>] ? __clear_user+0x23/0x67
[    0.802309]  [<ffffffff83f4120c>] clear_user+0x2e/0x30
[    0.802309]  [<ffffffff83e9e7a1>] load_elf_binary+0xa7f/0x18f7
[    0.802309]  [<ffffffff83de2088>] search_binary_handler+0x86/0x19c
[    0.802309]  [<ffffffff83de389e>] do_execveat_common.isra.26+0x909/0xf98
[    0.802309]  [<ffffffff844febe0>] ? rest_init+0x87/0x87
[    0.802309]  [<ffffffff83de40be>] do_execve+0x23/0x25
[    0.802309]  [<ffffffff83c002e3>] run_init_process+0x2b/0x2d
[    0.802309]  [<ffffffff844fec4d>] kernel_init+0x6d/0xda
[    0.802309]  [<ffffffff84505b2f>] ret_from_fork+0x3f/0x70
[    0.802309]  [<ffffffff844febe0>] ? rest_init+0x87/0x87
[    0.830559] Kernel panic - not syncing: Attempted to kill init!  exitcode=0x00000009
[    0.830559] 
[    0.831305] Kernel Offset: 0x2c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    0.831305] ---[ end Kernel panic - not syncing: Attempted to kill init!  exitcode=0x00000009

The crash part of this problem may be solved with the following patch (thanks to Hugh for the hint). There is still another problem, though - with this patch applied, the qemu session aborts with "VCPU Shutdown request", whatever that means.

Guenter

---
From: Guenter Roeck <[email protected]>
Date: Thu, 4 Jan 2018 13:41:55 -0800
Subject: [PATCH 2/2] WIP: kaiser: Set _PAGE_NX only if supported

Change-Id Ie6ab566c1d725b24c4b3aa80a47c3ff3a5feddb9
---
 arch/x86/mm/kaiser.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
arch/x86/mm/kaiser.c +0 -0
index 7d2f7eb6857f..e4706273d4a1 100644

arch/x86/mm/kaiser.c pgd_t kaiser_set_shadow_pgd(pgd_t *pgdp, pgd_t pgd) · line 428

Quoted 9 lines
arch/x86/mm/kaiser.c +2 -1
@@ -421,7 +421,8 @@ pgd_t kaiser_set_shadow_pgd(pgd_t *pgdp, pgd_t pgd)
 			 * get out to userspace running on the kernel CR3,
 			 * userspace will crash instead of running.
 			 */
-			pgd.pgd |= _PAGE_NX;
+			if (__supported_pte_mask & _PAGE_NX)
+				pgd.pgd |= _PAGE_NX;
 		}
 	} else if (!pgd.pgd) {
 		/*

Very good catch, this mirrors almost what is in 4.14 in this area. I'll go queue this up for 4.9 and 4.4 stable trees.

thanks,

greg k-h

#137 lore raw
Quoted 12 lines · Greg Kroah-Hartman
Quoted 11 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

This is also reported to crash if loaded under qemu + haxm under windows.

[ ... ]

Quoted 5 lines
Quoted 5 lines

The crash part of this problem may be solved with the following patch (thanks to Hugh for the hint). There is still another problem, though - with this patch applied, the qemu session aborts with "VCPU Shutdown request", whatever that means.

v4.4.110 still suffers from "VCPU Shutdown request" with qemu+haxm. Unfortunately I don't have any other information about the problem at this time.

Guenter

#138 lore raw
In reply to Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Quoted 9 lines

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

        kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.110-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

This patchset merges correctly with Gentoo patches and GCC version 6.4.0 The kernel boot up correctly.
Logs: http://kernel1.amd64.dev.gentoo.org:8010/#/builders/5/builds/44

Signature · 7 lines
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Gentoo Foundation Board Member
Mail: Alice Ferrazzi <[email protected]>
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A
author maintainer
#139 lore raw
Quoted 17 lines · Alice Ferrazzi
Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Quoted 9 lines

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

        kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.110-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

Quoted 3 lines

This patchset merges correctly with Gentoo patches and GCC version 6.4.0 The kernel boot up correctly.
Logs: http://kernel1.amd64.dev.gentoo.org:8010/#/builders/5/builds/44

Great, but Gentoo really should be moving to 4.9 and 4.14 here, I hope no one running Gentoo is relying on 4.4 :)

thanks,

greg k-h

#140 lore raw
Quoted 18 lines · Greg Kroah-Hartman
Quoted 17 lines · Alice Ferrazzi
Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

        kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.110-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

Quoted 6 lines
Quoted 3 lines

This patchset merges correctly with Gentoo patches and GCC version 6.4.0 The kernel boot up correctly.
Logs: http://kernel1.amd64.dev.gentoo.org:8010/#/builders/5/builds/44

Great, but Gentoo really should be moving to 4.9 and 4.14 here, I hope no one running Gentoo is relying on 4.4 :)

Wait what?

According to https://www.kernel.org/category/releases.html
4.4 should be the best bet for longest support, right? Does that page need to be updated? If 4.4 is not going to be supported, is there anything else with a possible 5-6 years of support?

author maintainer
#141 lore raw
Quoted 26 lines · Serge E. Hallyn
Quoted 18 lines · Greg Kroah-Hartman
Quoted 17 lines · Alice Ferrazzi
Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

        kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.110-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

Quoted 6 lines
Quoted 3 lines

This patchset merges correctly with Gentoo patches and GCC version 6.4.0 The kernel boot up correctly.
Logs: http://kernel1.amd64.dev.gentoo.org:8010/#/builders/5/builds/44

Great, but Gentoo really should be moving to 4.9 and 4.14 here, I hope no one running Gentoo is relying on 4.4 :)

Quoted 7 lines

Wait what?

According to https://www.kernel.org/category/releases.html
4.4 should be the best bet for longest support, right? Does that page need to be updated? If 4.4 is not going to be supported, is there anything else with a possible 5-6 years of support?

4.4 is going to be supported, yes, but really, for a desktop/server system, why would you ever want to stick with it for anything longer than a year? No new hardware support is added, and no new features that you would want are in there.

The LTS kernels are for the crazy embedded people that don't change their hardware systems, and have the insane huge number of out-of-tree patches. No one else should be using those kernels, they should always be using newer ones, as there are always more issues fixed in newer kernels than older ones.

So again, I hope no one running Gentoo, which is a rolling, constantly updated distro, is using the old and crusty 4.4 kernel release. To do so is to defeat the purpose of relying on Gentoo in the first place...

thanks,

greg k-h

#142 lore raw
Quoted 46 lines · Greg Kroah-Hartman
Quoted 26 lines · Serge E. Hallyn
Quoted 18 lines · Greg Kroah-Hartman
Quoted 17 lines · Alice Ferrazzi
Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

        kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.110-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

Quoted 6 lines
Quoted 3 lines

This patchset merges correctly with Gentoo patches and GCC version 6.4.0 The kernel boot up correctly.
Logs: http://kernel1.amd64.dev.gentoo.org:8010/#/builders/5/builds/44

Great, but Gentoo really should be moving to 4.9 and 4.14 here, I hope no one running Gentoo is relying on 4.4 :)

Quoted 7 lines

Wait what?

According to https://www.kernel.org/category/releases.html
4.4 should be the best bet for longest support, right? Does that page need to be updated? If 4.4 is not going to be supported, is there anything else with a possible 5-6 years of support?

4.4 is going to be supported, yes, but really, for a desktop/server system, why would you ever want to stick with it for anything longer than a year? No new hardware support is added, and no new features that you would want are in there.

The LTS kernels are for the crazy embedded people that don't change their hardware systems, and have the insane huge number of out-of-tree patches. No one else should be using those kernels, they should always be using newer ones, as there are always more issues fixed in newer kernels than older ones.

Quoted 3 lines

So again, I hope no one running Gentoo, which is a rolling, constantly updated distro, is using the old and crusty 4.4 kernel release. To do so is to defeat the purpose of relying on Gentoo in the first place...

Ah, I see, yeah that makes sense :)

thanks,
-serge

#143 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

Update: v4.4.110 final nosmp builds fail as follows:

------------
Error log:
arch/x86/entry/vdso/vma.c: In function ‘map_vdso’:
arch/x86/entry/vdso/vma.c:173:9: error:
implicit declaration of function ‘pvclock_pvti_cpu0_va’

Guenter

author maintainer
#144 lore raw
Quoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

Quoted 7 lines

Update: v4.4.110 final nosmp builds fail as follows:

------------
Error log:
arch/x86/entry/vdso/vma.c: In function ‘map_vdso’:
arch/x86/entry/vdso/vma.c:173:9: error:
implicit declaration of function ‘pvclock_pvti_cpu0_va’

x86-64 or i386?
That should be a CONFIG_PARAVIRT_CLOCK issue, not a smp build issue, have a .config I can try?

thanks,

greg k-h

#145 lore raw
Quoted 13 lines · Greg Kroah-Hartman
Quoted 12 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

Update: v4.4.110 final nosmp builds fail as follows:

Quoted 7 lines
Quoted 5 lines

------------
Error log:
arch/x86/entry/vdso/vma.c: In function ‘map_vdso’:
arch/x86/entry/vdso/vma.c:173:9: error:
implicit declaration of function ‘pvclock_pvti_cpu0_va’

x86-64 or i386?

x86-64

Quoted 3 lines

That should be a CONFIG_PARAVIRT_CLOCK issue, not a smp build issue, have a .config I can try?

https://github.com/groeck/linux-build-test/blob/master/rootfs/x86_64/qemu_x86_64_pc_nosmp_defconfig

However,
https://github.com/groeck/linux-build-test/blob/master/rootfs/x86_64/qemu_x86_64_pc_defconfig
does build, and the only differences are:

30a31

Quoted 1 line

CONFIG_SMP=y

32a34,35

Quoted 2 lines

CONFIG_NR_CPUS=24
CONFIG_SCHED_SMT=y

44d46
< CONFIG_ACPI_CONTAINER=y

Both configurations have CONFIG_PARAVIRT_CLOCK disabled.

Guenter

#146 lore raw
In reply to Greg Kroah-Hartman
Quoted 19 lines · Greg Kroah-Hartman
Quoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.110 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri Jan 5 19:50:38 UTC 2018. Anything received after that time might be too late.

Quoted 7 lines

Update: v4.4.110 final nosmp builds fail as follows:

------------
Error log:
arch/x86/entry/vdso/vma.c: In function ‘map_vdso’:
arch/x86/entry/vdso/vma.c:173:9: error:
implicit declaration of function ‘pvclock_pvti_cpu0_va’

Quoted 4 lines

x86-64 or i386?
That should be a CONFIG_PARAVIRT_CLOCK issue, not a smp build issue, have a .config I can try?

Here is an easier way to reproduce the problem: make allnoconfig ; make

Guenter