linux-kernel - [PATCH] x86/mm/kaiser: Fix IRQ entries text section mapping

lists.openwall.net		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 linux-hardening linux-cve-announce 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 <mingo@...nel.org>
To:     Andy Lutomirski <luto@...capital.net>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: [PATCH] x86/mm/kaiser: Fix IRQ entries text section mapping


* Ingo Molnar <mingo@...nel.org> 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.

Thanks,

	Ingo

=============>
>From 19bbacd5f7c66b4716716bad97848a9cacd6fe68 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@...nel.org>
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 <mingo@...nel.org>
---
 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,