Re: [PATCH v4 0/2] x86_64,entry: Clear NT on entry and speed up switch_to

From: Andy Lutomirski
Date: Fri Oct 31 2014 - 21:00:40 EST


On Fri, Oct 31, 2014 at 5:20 PM, Rusty Russell <rusty@xxxxxxxxxx> wrote:
> Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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 <luto@xxxxxxxxxxxxxx>
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/