On Fri, Oct 31, 2014 at 5:20 PM, Rusty Russell <[email protected]> wrote: > Andy Lutomirski <[email protected]> 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 <[email protected]> > 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: [<ffffffff8170703d>] 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:[<ffffffff8170703d>] [<ffffffff8170703d>] > 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] [<ffffffff8138aa0b>] ? 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 <f7> > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
