Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755114AbaDVSRd (ORCPT ); Tue, 22 Apr 2014 14:17:33 -0400 Received: from mail-la0-f41.google.com ([209.85.215.41]:65521 "EHLO mail-la0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750897AbaDVSRb (ORCPT ); Tue, 22 Apr 2014 14:17:31 -0400 MIME-Version: 1.0 In-Reply-To: <5356AF9F.4010301@zytor.com> References: <20140422112312.GB15882@pd.tnic> <20140422144659.GF15882@pd.tnic> <53569467.1030809@zytor.com> <5356A70A.5090907@zytor.com> <5356AF9F.4010301@zytor.com> Date: Tue, 22 Apr 2014 14:17:29 -0400 Message-ID: Subject: Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE* From: Brian Gerst To: "H. Peter Anvin" Cc: Andrew Lutomirski , 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 , 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 2:06 PM, H. Peter Anvin wrote: > On 04/22/2014 11:03 AM, Brian Gerst wrote: >> >> Maybe make the #GP handler check what the previous stack was at the start: >> 1) If we came from userspace, switch to the top of the process stack. >> 2) If the previous stack was not the espfix stack, switch back to that stack. >> 3) Switch to the top of the process stack (espfix case) >> >> This leaves the IST available for any recursive faults. >> > > Do you actually know what the IST is? If so, you should realize the > above is nonsense. > > The *hardware* switches stack on an exception; if the vector is set up > as an IST, then we *always* switch to the IST stack, unconditionally. > If the vector is not, then we switch to the process stack if we came > from userspace. > > That is the entry condition that we have to deal with. The fact that > the switch to the IST is unconditional is what makes ISTs hard to deal with. Right, that is why you switch away from the IST as soon as possible, copying the data that is already pushed there to another stack so it won't be overwritten by a recursive fault. -- 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/