lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 25 Nov 2017 12:17:21 +0100
From:   Ingo Molnar <>
To:     Andy Lutomirski <>,
        Dave Hansen <>,
        Josh Poimboeuf <>
Cc:, Andy Lutomirski <>,
        Thomas Gleixner <>,
        "H . Peter Anvin" <>,
        Peter Zijlstra <>,
        Borislav Petkov <>,
        Linus Torvalds <>
Subject: [PATCH] x86/mm/kaiser: Fix IRQ entries text section mapping

* Ingo Molnar <> wrote:

> > So it's either unwinder related, or seemingly minor changes to code 
> > alignment/placement will make the bug go away.
> Ok, I think the Orc unwinder is innocent: I just forced a build with frame 
> pointers but with ORC debuginfo and unwinder, and that is booting fine too.
> So it's the specific code size and alignment present in the config I sent that is 
> triggering the bug. Fudging that alignment/sizing with the workaround patch above 
> makes the crash go away.

Ok, after a few hours of debugging with Thomas today we found the bug: it was 
caused by Kaiser not mapping the __irqentry_text_start...__irqentry_text_end 
kernel virtual memory range, which the IRQ entry code requires before it switches 
to the kernel page tables.

This bug was hidden in most configs by virtue of:

 	kaiser_add_user_map_ptrs_early(__entry_text_start, __entry_text_end,
 				       __PAGE_KERNEL_RX | _PAGE_GLOBAL);

because the __irqentry_text_start...__irqentry_text_end kernel code section comes 
right after this section and is pretty small - so it usually fits into the last 
page of the mapping.

But for certain configs the __entry_text_start address crossed the next page 
boundary, and was not mapped - resulting in a page fault and then in a double 
fault as the entry stack overflowed.

The patch below fixes the crash, and after some testing I'll backmerge it to the 
core Kaiser patch in tip:WIP.x86/mm.

There's a few takeaways from this incident though:

 - Entry stack overflow debugging is pretty crude and should probably be improved.

 - We should better isolate all Kaiser-mapped sections and pad them out
   to page boundary. This would immediately trigger any simila false-sharing 
   side-effect mapping bugs and they wouldn't be .config dependent Heisenbugs.



>From 19bbacd5f7c66b4716716bad97848a9cacd6fe68 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <>
Date: Sat, 25 Nov 2017 12:10:38 +0100
Subject: [PATCH] x86/mm/kaiser: Fix IRQ entries text section mapping

Backmerge to:

  f9e7e52fa076: x86/mm/kaiser: Unmap kernel from userspace page tables (core patch)

Signed-off-by: Ingo Molnar <>
 arch/x86/mm/kaiser.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/mm/kaiser.c b/arch/x86/mm/kaiser.c
index 1eb27b410556..ea8887bf550a 100644
--- a/arch/x86/mm/kaiser.c
+++ b/arch/x86/mm/kaiser.c
@@ -412,6 +412,8 @@ void __init kaiser_init(void)
 	kaiser_add_user_map_ptrs_early(__entry_text_start, __entry_text_end,
 				       __PAGE_KERNEL_RX | _PAGE_GLOBAL);
+	kaiser_add_user_map_ptrs_early(__irqentry_text_start, __irqentry_text_end,
+				       __PAGE_KERNEL_RX | _PAGE_GLOBAL);
 	/* the fixed map address of the idt_table */
 	kaiser_add_user_map_early((void *)idt_descr.address,

Powered by blists - more mailing lists