[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230810132221.GB212435@hirez.programming.kicks-ass.net>
Date: Thu, 10 Aug 2023 15:22:21 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, David.Kaplan@....com,
Andrew.Cooper3@...rix.com, jpoimboe@...nel.org,
gregkh@...uxfoundation.org
Subject: Re: [RFC][PATCH 02/17] x86/cpu: Clean up SRSO return thunk mess
On Thu, Aug 10, 2023 at 02:56:31PM +0200, Borislav Petkov wrote:
> > Then both srso options use RSB/RAP stuffing to force a mispredict there.
>
> They cause the RETs to mispredict - no stuffing. That's the add $8,
> %rsp in the zen3/4 case which causes the RET to mispredict. There's no
> doing a bunch of CALLs to stuff something.
This is what is called RSB stuffing, we've been doing it for ages on the
Intel side, and code in nospec-branch.h has a number of variants of
this.
CALL srso_safe_ret // push addr of UD2 into RSB -- aka 'stuff'
UD2
srso_safe_ret:
ADD $8, %RSP // skip over the return to UD2
RET // pop RSB, speculate into UD2, miss like a beast
Now compare to __FILL_ONE_RETURN, which has the comment 'Stuff a single
RSB slot.' That expands to:
call 772f
int3
772: add $8, %rsp
lfence
Which is the same sequence and causes the next RET to speculate into
that int3.
So RSB stuffing is sticking addresses to traps in the RSB so that
subsequent predictions go into said traps instead of potentially user
controlled targets.
Powered by blists - more mailing lists