From: Peter Zijlstra <peterz@infradead.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: x86@kernel.org, jgross@suse.com, mbenes@suse.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 14/14] objtool,x86: Rewrite retpoline thunk calls
Date: Fri, 19 Mar 2021 09:06:44 +0100 [thread overview]
Message-ID: <YFRblERAnQu2KtZG@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20210319032955.zdx6ihhprem5owbc@treble>
On Thu, Mar 18, 2021 at 10:29:55PM -0500, Josh Poimboeuf wrote:
> On Thu, Mar 18, 2021 at 06:11:17PM +0100, Peter Zijlstra wrote:
> > When the compiler emits: "CALL __x86_indirect_thunk_\reg" for an
> > indirect call, have objtool rewrite it to:
> >
> > ALTERNATIVE "call __x86_indirect_thunk_\reg",
> > "call *%reg", ALT_NOT(X86_FEATURE_RETPOLINE)
> >
> > Additionally, in order to not emit endless identical
> > .altinst_replacement chunks, use a global symbol for them, see
> > __x86_indirect_alt_*.
> >
> > This also avoids objtool from having to do code generation.
> >
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>
> This is better than I expected. Nice workaround for not generating
> code.
Thanks :-)
> > +.macro ALT_THUNK reg
> > +
> > + .align 1
> > +
> > +SYM_FUNC_START_NOALIGN(__x86_indirect_alt_call_\reg)
> > + ANNOTATE_RETPOLINE_SAFE
> > +1: call *%\reg
> > +2: .skip 5-(2b-1b), 0x90
> > +SYM_FUNC_END(__x86_indirect_alt_call_\reg)
> > +
> > +SYM_FUNC_START_NOALIGN(__x86_indirect_alt_jmp_\reg)
> > + ANNOTATE_RETPOLINE_SAFE
> > +1: jmp *%\reg
> > +2: .skip 5-(2b-1b), 0x90
> > +SYM_FUNC_END(__x86_indirect_alt_jmp_\reg)
>
> This mysterious code needs a comment. Shouldn't it be in
> .altinstr_replacement or something?
Comment, yes, I suppose so. And no, if we stick it in
.altinstr_replacement we'll throw them away with initmem and module
alternative patching (which will also refer to these symbols) will go
side-ways.
> Also doesn't the alternative code already insert nops?
Problem is that the {call,jmp} *%\reg thing is not fixed length. They're
2 or 3 bytes depending on which register is picked.
We could make them all 3 long and insert 0,1 nop I suppose.
Initially alternatives wouldn't re-optimize nops on patched things, it
would simply add nops on. And I had the above be:
1: INSN *%\reg
2: .nops 5-(2b-1b)
and we'd get a single right sized nop. But the .nops directive it too
new, we support binutils that don't have it :/
Hence, it now reads:
2: .skip 5-(2b-1b), 0x90
End result is that alternative NOP optimizer patch at the start of the
series that now also optimizes a bunch of cases that are unrelated and
were previously missed -- but crucially, it covers this case too :-)
Anyway, yes I could make it 3 long.
> > +int arch_rewrite_retpoline(struct objtool_file *file,
> > + struct instruction *insn,
> > + struct reloc *reloc)
> > +{
> > + struct symbol *sym;
> > + char name[32] = "";
> > +
> > + if (!strcmp(insn->sec->name, ".text.__x86.indirect_thunk"))
> > + return 0;
> > +
> > + sprintf(name, "__x86_indirect_alt_%s_%s",
> > + insn->type == INSN_JUMP_DYNAMIC ? "jmp" : "call",
> > + reloc->sym->name + 21);
> > +
> > + sym = find_symbol_by_name(file->elf, name);
> > + if (!sym) {
> > + sym = elf_create_undef_symbol(file->elf, name);
> > + if (!sym) {
> > + WARN("elf_create_undef_symbol");
> > + return -1;
> > + }
> > + }
> > +
> > + elf_add_alternative(file->elf, insn, sym,
> > + ALT_NOT(X86_FEATURE_RETPOLINE), 5, 5);
> > +
> > + return 0;
> > +}
>
> Need to propagate the error.
Oh, indeed so.
next prev parent reply other threads:[~2021-03-19 8:07 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-18 17:11 [PATCH v2 00/14] x86,objtool: Optimize !RETPOLINE Peter Zijlstra
2021-03-18 17:11 ` [PATCH v2 01/14] x86: Add insn_decode_kernel() Peter Zijlstra
2021-03-19 10:40 ` Borislav Petkov
2021-03-18 17:11 ` [PATCH v2 02/14] x86/alternatives: Optimize optimize_nops() Peter Zijlstra
2021-03-21 12:06 ` Borislav Petkov
2021-03-22 8:17 ` Peter Zijlstra
2021-03-22 11:07 ` Borislav Petkov
2021-03-18 17:11 ` [PATCH v2 03/14] x86/retpoline: Simplify retpolines Peter Zijlstra
2021-03-19 17:18 ` David Laight
2021-03-22 9:32 ` Peter Zijlstra
2021-03-22 15:41 ` David Laight
2021-03-18 17:11 ` [PATCH v2 04/14] objtool: Correctly handle retpoline thunk calls Peter Zijlstra
2021-03-18 17:11 ` [PATCH v2 05/14] objtool: Per arch retpoline naming Peter Zijlstra
2021-03-19 2:38 ` Josh Poimboeuf
2021-03-19 9:07 ` Peter Zijlstra
2021-03-18 17:11 ` [PATCH v2 06/14] objtool: Fix static_call list generation Peter Zijlstra
2021-03-22 12:44 ` Miroslav Benes
2021-03-18 17:11 ` [PATCH v2 07/14] objtool: Rework rebuild_reloc logic Peter Zijlstra
2021-03-18 17:11 ` [PATCH v2 08/14] objtool: Add elf_create_reloc() helper Peter Zijlstra
2021-03-19 1:42 ` Josh Poimboeuf
2021-03-19 9:47 ` Peter Zijlstra
2021-03-19 15:12 ` Josh Poimboeuf
2021-03-19 15:24 ` Peter Zijlstra
2021-03-19 15:37 ` Josh Poimboeuf
2021-03-18 17:11 ` [PATCH v2 09/14] objtool: Extract elf_strtab_concat() Peter Zijlstra
2021-03-19 2:10 ` Josh Poimboeuf
2021-03-19 9:52 ` Peter Zijlstra
2021-03-18 17:11 ` [PATCH v2 10/14] objtool: Extract elf_symbol_add() Peter Zijlstra
2021-03-19 2:14 ` Josh Poimboeuf
2021-03-19 9:54 ` Peter Zijlstra
2021-03-19 15:04 ` Josh Poimboeuf
2021-03-18 17:11 ` [PATCH v2 11/14] objtool: Add elf_create_undef_symbol() Peter Zijlstra
2021-03-19 2:29 ` Josh Poimboeuf
2021-03-19 7:56 ` Peter Zijlstra
2021-03-18 17:11 ` [PATCH v2 12/14] objtool: Allow archs to rewrite retpolines Peter Zijlstra
2021-03-19 2:54 ` Josh Poimboeuf
2021-03-19 11:21 ` Peter Zijlstra
2021-03-19 13:28 ` Peter Zijlstra
2021-03-18 17:11 ` [PATCH v2 13/14] objtool: Skip magical retpoline .altinstr_replacement Peter Zijlstra
2021-03-18 17:11 ` [PATCH v2 14/14] objtool,x86: Rewrite retpoline thunk calls Peter Zijlstra
2021-03-19 3:29 ` Josh Poimboeuf
2021-03-19 8:06 ` Peter Zijlstra [this message]
2021-03-19 15:30 ` Josh Poimboeuf
2021-03-19 15:56 ` Peter Zijlstra
2021-03-19 22:52 ` Josh Poimboeuf
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=YFRblERAnQu2KtZG@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=jgross@suse.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbenes@suse.com \
--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.