[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YXmOs2oSp+6Dpi4R@zn.tnic>
Date: Wed, 27 Oct 2021 19:38:59 +0200
From: Borislav Petkov <bp@...en8.de>
To: Peter Zijlstra <peterz@...radead.org>
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 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.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists