From: Borislav Petkov <bp@alien8.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
x86@kernel.org, pjt@google.com, mbenes@suze.cz, jgross@suse.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 6/6] objtool,x86: Rewrite retpoline thunk calls
Date: Sat, 20 Feb 2021 18:41:01 +0100 [thread overview]
Message-ID: <20210220174101.GA29905@zn.tnic> (raw)
In-Reply-To: <YDE9bmaO4tOZ/HWn@hirez.programming.kicks-ass.net>
On Sat, Feb 20, 2021 at 05:48:46PM +0100, Peter Zijlstra wrote:
> - straight line execution is always better than a round-trip to
> somewhere else, no matter how trivial.
Sure, but not at that price. Especially not if it is waaay down in perf
profiles.
> - supposely EIBRS (yeah, I know, there's a paper out there) should
> result in no longer using retpolines.
Yap, supposedly both vendors have stuff like that in the works. When
that happens, we can finally use ALTERNATIVE_3 in the ratpolines. :-)
> - I really, as in _REALLY_ don't want to do a CET enabled retpoline
WTF is that? Can we deal with one atrocity at a time pls...
> - IOW, retpolines should be on their way out (knock on wood)
Yap, my hope too.
> - doing this was fun :-)
I know.
> - this stuff was mostly trivial make work stuff I could do with a head
> full of snot and a headache.
I don't want to imagine what you'd come up with when you're all healthy
and rested. :-P
> - if we had negative alternatives objtool doesn't need to actually
> rewrite code in this case. It could simply emit alternative entries
> and call it a day.
I don't mind the negative alt per se - I mind the implementation I saw.
I'm sure we can come up with something nicer, like, for example, struct
alt_instr.flags to denote that this feature is a NOT feature. IOW, I'd
like for the fact that a feature is a NOT feature or patching needs to
happen in the NOT case, to be explicitly stated with a flag. I.e.,
if (!boot_cpu_has(a->cpuid) && !(a->flags & PATCH_WHEN_X86_FEATURE_FLAG_NOT_SET))
continue;
Something like that.
> - objtool already rewrites code
Sure, as long as one can reconstruct from looking at the asm, what
objdool has changed. I fear that'll get out of control if not done with
restraint and proper documentation.
> - I have more cases for objtool to rewrite code (I'll see if I can
> rebase and post that this weekend -- no promises).
Oh noes.
> - also https://lkml.kernel.org/r/20200625200235.GQ4781@hirez.programming.kicks-ass.net
Oh well, I guess you can simply make objtool compile the kernel and be
done with it.
:)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-02-20 17:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-19 20:43 [RFC][PATCH 0/6] objtool: Optimize !retpoline Peter Zijlstra
2021-02-19 20:43 ` [RFC][PATCH 1/6] objtool: Correctly handle retpoline thunk calls Peter Zijlstra
2021-02-19 20:43 ` [RFC][PATCH 2/6] objtool: Fix static_call list generation Peter Zijlstra
2021-02-19 20:43 ` [RFC][PATCH 3/6] objtool: Rework rebuild_reloc logic Peter Zijlstra
2021-02-19 20:43 ` [RFC][PATCH 4/6] objtool: Add elf_create_undef_symbol() Peter Zijlstra
2021-02-19 20:43 ` [RFC][PATCH 5/6] objtool: Allow archs to rewrite retpolines Peter Zijlstra
2021-02-19 20:43 ` [RFC][PATCH 6/6] objtool,x86: Rewrite retpoline thunk calls Peter Zijlstra
2021-02-19 21:55 ` Josh Poimboeuf
2021-02-19 22:01 ` Peter Zijlstra
2021-02-20 0:39 ` Borislav Petkov
2021-02-20 16:48 ` Peter Zijlstra
2021-02-20 17:41 ` Borislav Petkov [this message]
2021-02-20 22:28 ` Peter Zijlstra
2021-02-20 22:51 ` Peter Zijlstra
2021-02-21 9:54 ` Borislav Petkov
2021-02-20 22:32 ` Peter Zijlstra
2021-02-21 5:45 ` Jürgen Groß
2021-02-21 9:44 ` Borislav Petkov
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=20210220174101.GA29905@zn.tnic \
--to=bp@alien8.de \
--cc=jgross@suse.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbenes@suze.cz \
--cc=peterz@infradead.org \
--cc=pjt@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).