From: Andy Lutomirski <luto@amacapital.net>
To: Rusty Russell <rusty@ozlabs.org>
Cc: Thomas Gleixner <tglx@linutronix.de>, X86 ML <x86@kernel.org>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Sebastian Lackner <sebastian@fds-team.de>,
Anish Bhatt <anish@chelsio.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Chuck Ebbert <cebbert.lkml@gmail.com>
Subject: Re: [PATCH v4 0/2] x86_64,entry: Clear NT on entry and speed up switch_to
Date: Fri, 31 Oct 2014 18:00:14 -0700 [thread overview]
Message-ID: <CALCETrWJ4-PaLpceb7NCm6pKgkNXh77x1F6XHHxafcvBRFAoxg@mail.gmail.com> (raw)
In-Reply-To: <877fzf4vqg.fsf@rustcorp.com.au>
On Fri, Oct 31, 2014 at 5:20 PM, Rusty Russell <rusty@ozlabs.org> wrote:
> Andy Lutomirski <luto@amacapital.net> 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@amacapital.net>
> 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.
next prev parent reply other threads:[~2014-11-01 1:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-01 18:49 [PATCH v4 0/2] x86_64,entry: Clear NT on entry and speed up switch_to Andy Lutomirski
2014-10-01 18:49 ` [PATCH v4 1/2] x86_64,entry: Filter RFLAGS.NT on entry from userspace Andy Lutomirski
2014-10-01 19:49 ` Andy Lutomirski
2014-10-02 15:36 ` H. Peter Anvin
2014-10-06 16:42 ` H. Peter Anvin
2014-10-06 18:07 ` [tip:x86/urgent] x86_64, entry: " tip-bot for Andy Lutomirski
2014-10-01 18:49 ` [PATCH v4 2/2] x86_64: Don't save flags on context switch Andy Lutomirski
2014-10-06 16:39 ` [PATCH v4 0/2] x86_64,entry: Clear NT on entry and speed up switch_to Andy Lutomirski
2014-10-06 16:41 ` H. Peter Anvin
2014-10-06 16:45 ` Andy Lutomirski
2014-10-06 16:57 ` H. Peter Anvin
2014-11-01 0:20 ` Rusty Russell
2014-11-01 1:00 ` Andy Lutomirski [this message]
2014-11-01 1:08 ` [PATCH] x86_64, entry: Fix out of bounds read on sysenter Andy Lutomirski
2014-11-01 2:28 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALCETrWJ4-PaLpceb7NCm6pKgkNXh77x1F6XHHxafcvBRFAoxg@mail.gmail.com \
--to=luto@amacapital.net \
--cc=anish@chelsio.com \
--cc=cebbert.lkml@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rusty@ozlabs.org \
--cc=sebastian@fds-team.de \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).