Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933579AbaDVRqb (ORCPT ); Tue, 22 Apr 2014 13:46:31 -0400 Received: from mail-vc0-f169.google.com ([209.85.220.169]:37605 "EHLO mail-vc0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932927AbaDVRq3 (ORCPT ); Tue, 22 Apr 2014 13:46:29 -0400 MIME-Version: 1.0 In-Reply-To: <5356A70A.5090907@zytor.com> References: <20140422112312.GB15882@pd.tnic> <20140422144659.GF15882@pd.tnic> <53569467.1030809@zytor.com> <5356A70A.5090907@zytor.com> From: Andrew Lutomirski Date: Tue, 22 Apr 2014 10:46:08 -0700 Message-ID: Subject: Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE* To: "H. Peter Anvin" Cc: Linus Torvalds , 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:29 AM, H. Peter Anvin wrote: > On 04/22/2014 10:19 AM, Linus Torvalds wrote: >> On Tue, Apr 22, 2014 at 10:11 AM, Andrew Lutomirski wrote: >>> >>>> >>>> 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? >> >> Just test bit #2. Don't do anything else if it's clear, because you >> should be done. You don't need to do anything special if it's clear, >> because I don't *think* we have any 16-bit data segments in the GDT on >> x86-64. >> > > And we don't (neither do we on i386, and we depend on that invariance.) > > Hence: > > irq_return: > + /* > + * Are we returning to the LDT? Note: in 64-bit mode > + * SS:RSP on the exception stack is always valid. > + */ > + testb $4,(SS-RIP)(%rsp) > + jnz irq_return_ldt > + > +irq_return_iret: > INTERRUPT_RETURN > - _ASM_EXTABLE(irq_return, bad_iret) > + _ASM_EXTABLE(irq_return_iret, bad_iret) > > > That is the whole impact of the IRET path. > > If using IST for #GP won't cause trouble (ISTs don't nest, so we need to > make sure there is absolutely no way we could end up nested) then the > rest of the fixup code can go away and we kill the common path > exception-handling overhead; the only new overhead is the IST > indirection for #GP, which isn't a performance-critical fault (good > thing, because untangling #GP faults is a major effort.) I'd be a bit nervous about read_msr_safe and friends. Also, what happens if userspace triggers a #GP and the signal stack setup causes a page fault? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/