From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933464AbaDVRL1 (ORCPT ); Tue, 22 Apr 2014 13:11:27 -0400 Received: from mail-ve0-f177.google.com ([209.85.128.177]:35994 "EHLO mail-ve0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933025AbaDVRLZ (ORCPT ); Tue, 22 Apr 2014 13:11:25 -0400 MIME-Version: 1.0 In-Reply-To: References: <5355A9E9.9070102@zytor.com> <1dbe8155-58da-45c2-9dc0-d9f4b5a6e643@email.android.com> <20140422112312.GB15882@pd.tnic> <20140422144659.GF15882@pd.tnic> <53569467.1030809@zytor.com> From: Andrew Lutomirski Date: Tue, 22 Apr 2014 10:11:04 -0700 Message-ID: Subject: Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE* To: Linus Torvalds Cc: "H. Peter Anvin" , Borislav Petkov , "H. Peter Anvin" , Linux Kernel Mailing List , Ingo Molnar , Alexander van Heukelum , Konrad Rzeszutek Wilk , Boris Ostrovsky , Arjan van de Ven , Brian Gerst , Alexandre Julliard , Andi Kleen , Thomas Gleixner 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 Tue, Apr 22, 2014 at 10:04 AM, Linus Torvalds wrote: > On Tue, Apr 22, 2014 at 10:00 AM, Andrew Lutomirski 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