From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9582533E36D for ; Tue, 6 Jan 2026 15:20:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767712820; cv=none; b=i93vzbJVYlucjZXyX3vRP9ul/ovcOcXS+ukSOMW4bpo3WCIdWRSAepZNfAmo94xdZyaR3g4AF2favdZbW0eJfAdTOZkFhxHZ7hEGCPcESEwCyJoylFf3ipzgyfvcqqHIG3LILBaHmFOPdErg+QNvPHwGL4KyyWP6LvDFC23kGFU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767712820; c=relaxed/simple; bh=v65K8UQo8hCpz0eETdBqgD/1nfTjBWXGVBoQXGZCRTI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iVxjHnU+pufbIHy3GL+5XqqovkmZzSF2RrisBXOT0mh5hojbq7W8V/BazIAv3yHmzX86WQBOBrDG4bxn2lC6HnXa5K/XpDU05JSo8AbygVWnBWOfT7h362gY2MBoyB/3lsU8CPgdlyaNG5LdWtQ0vY3G4+alTgDCozcrdcGH/I8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=jQA7cJW2; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="jQA7cJW2" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=GP6Yt0NB69WnAK3yKiA0179MO3b/jCdf9/JhJiesBc0=; b=jQA7cJW2fBsdn1HQTRU0g4iJB+ pnzLwsMUFYTRFfzhifd3f7V0qNPzCLbTPTl7TXMVAEgOtTuWvY21qaaBhFOlyIvMH/46sgkwcp9/Z AW1m/h10AfcZ9m4fao/N8ONELHotNjUvTgqfYf9tNOl6neJmLxxpkL46PKlmyZU77Zy3q810JjQqZ IAjFfU0YhS45AMu3UjGNX4lRIUNqRlJ+8N6gwBsnDiRvCt1LtmvwqKJF+1d/uwdgumvylEodrlWFm 0w8qaUCddTkiQogc3fY5c04vXDcWdsh4cs0bUaAWPL4xjgEZvb5Ncd68vamel+5bfcPuwqxv5X58Z 2S+cBTvg==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vd8qv-0000000BxY7-3Hmo; Tue, 06 Jan 2026 15:20:09 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 7F78C30056B; Tue, 06 Jan 2026 16:20:08 +0100 (CET) Date: Tue, 6 Jan 2026 16:20:08 +0100 From: Peter Zijlstra To: Andrew Cooper Cc: LKML , Xin Li , "H. Peter Anvin" , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Subject: Re: [PATCH] x86/fred: Correct speculative safety in fred_extint() Message-ID: <20260106152008.GZ3707891@noisy.programming.kicks-ass.net> References: <20260106131504.679932-1-andrew.cooper3@citrix.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260106131504.679932-1-andrew.cooper3@citrix.com> On Tue, Jan 06, 2026 at 01:15:04PM +0000, Andrew Cooper wrote: > array_index_nospec() is no use if the result gets spilled to the stack, as > it makes the believed safe-under-speculation value subject to memory > predictions. > > For all practical purposes, this means array_index_nospec() must be used in > the expression that accesses the array. > > As the code currently stands, it's the wrong side of irqentry_enter(), and > 'index' is put into %ebp across the function call. > > Remove the index variable and reposition array_index_nospec(), so it's > calculated immediately before the array access. > > Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") > Signed-off-by: Andrew Cooper I suppose I can go stick this in x86/urgent or so. > This is why we have array_access_nospec() in Xen, so you can't separate the > safety calculation from the array access. > > The observant reader might notice that the result of reading sysvec_table[] is > also subject to memory predictions. Aren't CPUs wonderful... > > In practice, even having array_index_nospec() part of the array access > expression is no guarantee of avoiding spilling to the stack. KASAN is liable > to hide a function call behind the scenes, while UBSAN is very good at > inserting it's own unsafe range checks around objects it knows the size of. > Aren't compilers wonderful... Yeah, then again nobody should be running *SAN kernels in production, right ;-) > --- > arch/x86/entry/entry_fred.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c > index 94e626cc6a07..4fc5b176d3ed 100644 > --- a/arch/x86/entry/entry_fred.c > +++ b/arch/x86/entry/entry_fred.c > @@ -159,8 +159,6 @@ void __init fred_complete_exception_setup(void) > static noinstr void fred_extint(struct pt_regs *regs) > { > unsigned int vector = regs->fred_ss.vector; > - unsigned int index = array_index_nospec(vector - FIRST_SYSTEM_VECTOR, > - NR_SYSTEM_VECTORS); > > if (WARN_ON_ONCE(vector < FIRST_EXTERNAL_VECTOR)) > return; > @@ -169,7 +167,8 @@ static noinstr void fred_extint(struct pt_regs *regs) > irqentry_state_t state = irqentry_enter(regs); > > instrumentation_begin(); > - sysvec_table[index](regs); > + sysvec_table[array_index_nospec(vector - FIRST_SYSTEM_VECTOR, > + NR_SYSTEM_VECTORS)](regs); > instrumentation_end(); > irqentry_exit(regs, state); > } else {