[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211027191054.GM174703@worktop.programming.kicks-ass.net>
Date: Wed, 27 Oct 2021 21:10:54 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, jpoimboe@...hat.com, andrew.cooper3@...rix.com,
linux-kernel@...r.kernel.org, alexei.starovoitov@...il.com,
ndesaulniers@...gle.com, bpf@...r.kernel.org
Subject: Re: [PATCH v3 10/16] x86/alternative: Implement .retpoline_sites
support
On Wed, Oct 27, 2021 at 07:38:59PM +0200, Borislav Petkov wrote:
> On Tue, Oct 26, 2021 at 02:01:42PM +0200, Peter Zijlstra wrote:
> > +static int patch_retpoline(void *addr, struct insn *insn, u8 *bytes)
> > +{
> > + retpoline_thunk_t *target;
> > + int reg, i = 0;
> > +
> > + target = addr + insn->length + insn->immediate.value;
> > + reg = target - __x86_indirect_thunk_array;
> > +
> > + if (WARN_ON_ONCE(reg & ~0xf))
> > + return -1;
> > +
> > + /* If anyone ever does: CALL/JMP *%rsp, we're in deep trouble. */
> > + BUG_ON(reg == 4);
> > +
> > + if (cpu_feature_enabled(X86_FEATURE_RETPOLINE))
> > + return -1;
>
> I wanna say this should be the first thing being checked on function
> entry but I get the feeling you'll be looking at other X86_FEATURE bits
> in future patches... /me goes into the future...
>
> yap, you do. Lemme look at the whole thing first then.
I wanted the sanity checks done unconditionally.
Powered by blists - more mailing lists