All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [RFC] x86/kvm/emulate: Avoid RET for fastops
Date: Wed, 29 Nov 2023 08:20:53 +0100	[thread overview]
Message-ID: <20231129072053.GA30650@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <ZWaV8H9e8ubhFgWJ@google.com>

On Tue, Nov 28, 2023 at 05:37:52PM -0800, Sean Christopherson wrote:
> On Sun, Nov 12, 2023, Peter Zijlstra wrote:
> > Hi,
> > 
> > Inspired by the likes of ba5ca5e5e6a1 ("x86/retpoline: Don't clobber
> > RFLAGS during srso_safe_ret()") I had it on my TODO to look at this,
> > because the call-depth-tracking rethunk definitely also clobbers flags
> > and that's a ton harder to fix.
> > 
> > Looking at this recently I noticed that there's really only one callsite
> > (twice, the testcc thing is basically separate from the rest of the
> > fastop stuff) and thus CALL+RET is totally silly, we can JMP+JMP.
> > 
> > The below implements this, and aside from objtool going apeshit (it
> > fails to recognise the fastop JMP_NOSPEC as a jump-table and instead
> > classifies it as a tail-call), it actually builds and the asm looks
> > good sensible enough.
> > 
> > I've not yet figured out how to test this stuff, but does something like
> > this look sane to you guys?
> 
> Yes?  The idea seems sound, but I haven't thought _that_ hard about whether or not
> there's any possible gotchas.   I did a quick test and nothing exploded (and
> usually when this code breaks, it breaks spectacularly).

That's encouraging..

> > Given that rethunks are quite fat and slow, this could be sold as a
> > performance optimization I suppose.
> > 
> > ---
> > 
> > diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
> > index f93e9b96927a..2cd3b5a46e7a 100644
> > --- a/arch/x86/include/asm/nospec-branch.h
> > +++ b/arch/x86/include/asm/nospec-branch.h
> > @@ -412,6 +412,17 @@ static inline void call_depth_return_thunk(void) {}
> >  	"call *%[thunk_target]\n",				\
> >  	X86_FEATURE_RETPOLINE_LFENCE)
> >  
> > +# define JMP_NOSPEC						\
> > +	ALTERNATIVE_2(						\
> > +	ANNOTATE_RETPOLINE_SAFE					\
> > +	"jmp *%[thunk_target]\n",				\
> > +	"jmp __x86_indirect_thunk_%V[thunk_target]\n",		\
> > +	X86_FEATURE_RETPOLINE,					\
> > +	"lfence;\n"						\
> > +	ANNOTATE_RETPOLINE_SAFE					\
> > +	"jmp *%[thunk_target]\n",				\
> > +	X86_FEATURE_RETPOLINE_LFENCE)
> 
> There needs a 32-bit version (eww) and a CONFIG_RETPOLINE=n version. :-/

I'll go make that happen. Thanks!

  reply	other threads:[~2023-11-29  7:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-12 20:12 [RFC] x86/kvm/emulate: Avoid RET for fastops Peter Zijlstra
2023-11-29  1:37 ` Sean Christopherson
2023-11-29  7:20   ` Peter Zijlstra [this message]
2023-11-29 15:04   ` 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=20231129072053.GA30650@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.