[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAObL_7EL8P0jgnjxkngqso47eFpYXHStNkvpzxSG_xCYgnaHng@mail.gmail.com>
Date: Tue, 22 Apr 2014 10:11:04 -0700
From: Andrew Lutomirski <amluto@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Alexander van Heukelum <heukelum@...tmail.fm>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Arjan van de Ven <arjan.van.de.ven@...el.com>,
Brian Gerst <brgerst@...il.com>,
Alexandre Julliard <julliard@...ehq.com>,
Andi Kleen <andi@...stfloor.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*
On Tue, Apr 22, 2014 at 10:04 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, Apr 22, 2014 at 10:00 AM, Andrew Lutomirski <amluto@...il.com> wrote:
>>
>> My point is that it may be safe to remove the special espfix fixup
>> from #PF, which is probably the most performance-critical piece here,
>> aside from iret itself.
>
> Actually, even that is unsafe.
>
> Why?
>
> The segment table is shared for a process. So you can have one thread
> doing a load_ldt() that invalidates a segment, while another thread is
> busy taking a page fault. The segment was valid at page fault time and
> is saved on the kernel stack, but by the time the page fault returns,
> it is no longer valid and the iretq will fault.
Let me try that again: I think it should be safe to remove the check
for "did we fault from the espfix stack" from the #PF entry. You can
certainly have all kinds of weird things happen on return from #PF,
but the overhead that I'm talking about is a test on exception *entry*
to see whether the fault happened on the espfix stack so that we can
switch back to running on a real stack.
If the espfix code and the iret at the end can't cause #PF, then the
check in #PF entry can be removed, I think.
>
> Anyway, if done correctly, this whole espfix should be totally free
> for normal processes, since it should only trigger if SS is a LDT
> entry (bit #2 set in the segment descriptor). So the normal fast-path
> should just have a simple test for that.
How? Doesn't something still need to check whether SS is funny before
doing iret?
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists