Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760084AbaKABAi (ORCPT ); Fri, 31 Oct 2014 21:00:38 -0400 Received: from mail-la0-f44.google.com ([209.85.215.44]:59385 "EHLO mail-la0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753399AbaKABAh (ORCPT ); Fri, 31 Oct 2014 21:00:37 -0400 MIME-Version: 1.0 In-Reply-To: <877fzf4vqg.fsf@rustcorp.com.au> References: <877fzf4vqg.fsf@rustcorp.com.au> From: Andy Lutomirski Date: Fri, 31 Oct 2014 18:00:14 -0700 Message-ID: Subject: Re: [PATCH v4 0/2] x86_64,entry: Clear NT on entry and speed up switch_to To: Rusty Russell Cc: Thomas Gleixner , X86 ML , Ingo Molnar , "H. Peter Anvin" , Sebastian Lackner , Anish Bhatt , "linux-kernel@vger.kernel.org" , Chuck Ebbert Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 31, 2014 at 5:20 PM, Rusty Russell wrote: > Andy Lutomirski writes: >> Anish Bhatt noticed that user programs can set RFLAGS.NT before >> syscall or sysenter, and the kernel entry code doesn't filter out >> NT. This causes kernel C code and, depending on thread flags, the >> exit slow path to run with NT set. > > OK, this causes oopsen as a guest under kvm for me. Details below: > > commit 8c7aa698baca5e8f1ba9edb68081f1e7a1abf455 > Author: Andy Lutomirski > Date: Wed Oct 1 11:49:04 2014 -0700 > > x86_64, entry: Filter RFLAGS.NT on entry from userspace Well, crap. > > Some dmesg: > > [ 1.126953] BUG: unable to handle kernel paging request at ffff88001da4c018 > [ 1.128482] IP: [] ia32_sysenter_target+0x4d/0x5e > [ 1.129513] PGD 2d6c067 PUD 2d6d067 PMD 1fdf4067 PTE 800000001da4c060 > [ 1.129513] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC > [ 1.129513] Modules linked in: > [ 1.129513] CPU: 0 PID: 69 Comm: init Not tainted 3.17.0-rc7+ #245 > [ 1.129513] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_171129-lamiak 04/01/2014 > [ 1.129513] task: ffff88001da08000 ti: ffff88001da48000 task.ti: ffff88001da48000 > [ 1.129513] RIP: 0010:[] [] ia32_sysenter_target+0x4d/0x5e > [ 1.129513] RSP: 0018:ffff88001da4bf88 EFLAGS: 00010296 So we're 0x78 bytes below the page boundary... > [ 1.129513] RAX: 0000000000000137 RBX: 00000000f754e730 RCX: 000000000000000c > [ 1.129513] RDX: 00000000f7711000 RSI: 0000000000000000 RDI: 00000000f77c3040 > [ 1.129513] RBP: 00000000ffca97c8 R08: ffffffff8138aa0b R09: 00000000ffcaba58 > [ 1.129513] R10: 00000000f77a1b70 R11: 0000000000000000 R12: 0000000000000000 > [ 1.129513] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > [ 1.129513] FS: 0000000000000000(0000) GS:ffff88001fa00000(0063) knlGS:00000000f754e6c0 > [ 1.129513] CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b > [ 1.129513] CR2: ffff88001da4c018 CR3: 000000001da2c000 CR4: 00000000000006f0 > [ 1.129513] Stack: > [ 1.129513] 0000000000000000 0000000000000000 00000000ffcaba58 ffffffff8138aa0b > [ 1.129513] 0000000000000137 000000000000000c 00000000f7711000 0000000000000000 > [ 1.129513] 00000000f77c3040 0000000000000137 00000000f77a1b70 0000000000000023 > [ 1.129513] Call Trace: > [ 1.129513] [] ? trace_hardirqs_on_thunk+0x3a/0x3f > [ 1.129513] Code: c0 41 52 50 fc 48 83 ec 48 48 89 7c 24 40 48 89 74 24 38 48 89 54 24 30 48 89 4c 24 28 48 89 44 24 20 66 66 90 8b 6d 00 66 66 90 84 24 90 00 00 00 00 40 00 00 0f 85 2f 01 00 00 83 8c 24 8c 0: c0 41 52 50 rolb $0x50,0x52(%rcx) 4: fc cld 5: 48 83 ec 48 sub $0x48,%rsp 9: 48 89 7c 24 40 mov %rdi,0x40(%rsp) e: 48 89 74 24 38 mov %rsi,0x38(%rsp) 13: 48 89 54 24 30 mov %rdx,0x30(%rsp) 18: 48 89 4c 24 28 mov %rcx,0x28(%rsp) 1d: 48 89 44 24 20 mov %rax,0x20(%rsp) 22: 66 66 90 data32 xchg %ax,%ax 25: 8b 6d 00 mov 0x0(%rbp),%ebp 28: 66 66 90 data32 xchg %ax,%ax 2b:* f7 84 24 90 00 00 00 testl $0x4000,0x90(%rsp) <-- trapping instruction This seems to be just slightly out of bounds. [Insert large number of expletives here] This is really bad. It worked when I tested it because of dumb luck. If I read random garbage there, there's a pretty good chance that the code will work. But somehow you're right at the end of the entire memory map, and you're totally screwed. Fix coming. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/