mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	David.Kaplan@amd.com, Andrew.Cooper3@citrix.com,
	jpoimboe@kernel.org, gregkh@linuxfoundation.org
Subject: Re: [RFC][PATCH 02/17] x86/cpu: Clean up SRSO return thunk mess
Date: Thu, 10 Aug 2023 15:22:21 +0200	[thread overview]
Message-ID: <20230810132221.GB212435@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20230810125631.GJZNTef8zQWjoA9KYB@fat_crate.local>

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.


  reply	other threads:[~2023-08-10 13:22 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-09  7:12 [RFC][PATCH 00/17] Fix up the recent SRSO patches Peter Zijlstra
2023-08-09  7:12 ` [RFC][PATCH 01/17] x86/alternative: Unconditional custom return thunk Peter Zijlstra
2023-08-09  9:31   ` Nikolay Borisov
2023-08-10 11:37   ` Borislav Petkov
2023-08-09  7:12 ` [RFC][PATCH 02/17] x86/cpu: Clean up SRSO return thunk mess Peter Zijlstra
2023-08-09 15:45   ` Nikolay Borisov
2023-08-10 11:51   ` Borislav Petkov
2023-08-10 12:37     ` Peter Zijlstra
2023-08-10 12:56       ` Borislav Petkov
2023-08-10 13:22         ` Peter Zijlstra [this message]
2023-08-11  7:01       ` Peter Zijlstra
2023-08-11 17:00         ` Nick Desaulniers
2023-08-12 11:20           ` Peter Zijlstra
2023-08-09  7:12 ` [RFC][PATCH 03/17] x86/cpu: Make srso_untrain_ret consistent Peter Zijlstra
2023-08-10 12:00   ` Borislav Petkov
2023-08-09  7:12 ` [RFC][PATCH 04/17] objtool/x86: Fix SRSO mess Peter Zijlstra
2023-08-10 12:06   ` Borislav Petkov
2023-08-10 12:48     ` Peter Zijlstra
2023-08-10 12:50       ` Peter Zijlstra
2023-08-10 15:02         ` Borislav Petkov
2023-08-10 15:22           ` Peter Zijlstra
2023-08-09  7:12 ` [RFC][PATCH 05/17] x86/cpu: Cleanup the untrain mess Peter Zijlstra
2023-08-09 12:51   ` Josh Poimboeuf
2023-08-09 13:12     ` Peter Zijlstra
2023-08-09 13:26       ` Peter Zijlstra
2023-08-12 18:30         ` Borislav Petkov
2023-08-09  7:12 ` [RFC][PATCH 06/17] x86/cpu: Add SRSO untrain to retbleed= Peter Zijlstra
2023-08-09 13:42   ` Josh Poimboeuf
2023-08-09 14:06     ` Peter Zijlstra
2023-08-09 14:28       ` Josh Poimboeuf
2023-08-09 15:08         ` Peter Zijlstra
2023-08-09 15:43           ` Josh Poimboeuf
2023-08-09 14:31     ` Andrew.Cooper3
2023-08-09 14:39       ` Josh Poimboeuf
2023-08-10 15:44   ` Borislav Petkov
2023-08-10 16:10     ` Josh Poimboeuf
2023-08-11 10:27       ` Borislav Petkov
2023-08-12 11:32         ` Peter Zijlstra
2023-08-12 12:12           ` Borislav Petkov
2023-08-14 15:45           ` David Laight
2023-08-12 11:24       ` Peter Zijlstra
2023-08-12 12:10         ` Borislav Petkov
2023-08-14 10:56           ` Peter Zijlstra
2023-08-09  7:12 ` [RFC][PATCH 07/17] x86/cpu/kvm: Provide UNTRAIN_RET_VM Peter Zijlstra
2023-08-09 13:50   ` Josh Poimboeuf
2023-08-09 14:06     ` Peter Zijlstra
2023-08-09 14:30       ` Josh Poimboeuf
2023-08-09 15:10         ` Peter Zijlstra
2023-08-13 10:36   ` Borislav Petkov
2023-08-14 10:35     ` Peter Zijlstra
2023-08-09  7:12 ` [RFC][PATCH 08/17] x86/cpu: Add IBPB on VMEXIT to retbleed= Peter Zijlstra
2023-08-09  7:12 ` [RFC][PATCH 09/17] x86: Remove CONFIG_CPU_SRSO Peter Zijlstra
2023-08-09 13:57   ` Josh Poimboeuf
2023-08-09  7:12 ` [RFC][PATCH 10/17] x86: Remove CPU_IBPB_ENTRY Peter Zijlstra
2023-08-09  7:12 ` [RFC][PATCH 11/17] x86/cpu: Remove all SRSO interface nonsense Peter Zijlstra
2023-08-09 13:10   ` Andrew.Cooper3
2023-08-09 13:36     ` Peter Zijlstra
2023-08-09 14:05   ` Josh Poimboeuf
2023-08-09 14:43     ` Peter Zijlstra
2023-08-09 14:51       ` Josh Poimboeuf
2023-08-09 15:34   ` Josh Poimboeuf
2023-08-09  7:12 ` [RFC][PATCH 12/17] x86/cpu: Rename original retbleed return thunk Peter Zijlstra
2023-08-09 14:20   ` Josh Poimboeuf
2023-08-09 14:22     ` Peter Zijlstra
2023-08-10 11:06       ` Andrew.Cooper3
2023-08-10 13:02         ` Peter Zijlstra
2023-08-13 15:23           ` Andrew.Cooper3
2023-08-14 10:34             ` Peter Zijlstra
2023-08-14 11:31               ` Andrew.Cooper3
2023-08-14 12:06                 ` Peter Zijlstra
2023-08-09  7:12 ` [RFC][PATCH 13/17] objtool/x86: Add arch_is_offset_insn() Peter Zijlstra
2023-08-09  9:56   ` Nikolay Borisov
2023-08-09 14:34   ` Josh Poimboeuf
2023-08-09  7:12 ` [RFC][PATCH 14/17] objtool: Add comments to the arch_is_$foo() magic symbols Peter Zijlstra
2023-08-09  7:12 ` [RFC][PATCH 15/17] x86/cpu: Rename srso_(.*)_alias to srso_alias_\1 Peter Zijlstra
2023-08-09  7:12 ` [RFC][PATCH 16/17] x86/alternatives: Simplify ALTERNATIVE_n() Peter Zijlstra
2023-08-09  7:12 ` [RFC][PATCH 17/17] x86/cpu: Use fancy alternatives to get rid of entry_untrain_ret() Peter Zijlstra
2023-08-09  9:04 ` [RFC][PATCH 00/17] Fix up the recent SRSO patches Nikolay Borisov
2023-08-09 10:04 ` Andrew.Cooper3
2023-08-09 11:58   ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230810132221.GB212435@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=David.Kaplan@amd.com \
    --cc=bp@alien8.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®