From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
Mark Rutland <mark.rutland@arm.com>,
Jason Baron <jbaron@akamai.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ard Biesheuvel <ardb@kernel.org>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>
Subject: Re: [RFC][PATCH 1/5] static_call: Make NULL static calls consistent
Date: Fri, 10 Mar 2023 17:20:04 -0800 [thread overview]
Message-ID: <20230311012004.vyc4kdlqjsv4zliw@treble> (raw)
In-Reply-To: <20230310205926.GB1605437@hirez.programming.kicks-ass.net>
On Fri, Mar 10, 2023 at 09:59:26PM +0100, Peter Zijlstra wrote:
> > -#define __static_call_cond(name) \
> > -({ \
> > - void *func = READ_ONCE(STATIC_CALL_KEY(name).func); \
> > - if (!func) \
> > - func = &__static_call_nop; \
> > - (typeof(STATIC_CALL_TRAMP(name))*)func; \
> > -})
>
> So a sufficiently clever compiler can optimize the above to avoid the
> actual indirect call (and resulting CFI violation, see below), because
> __static_call_nop() is inline and hence visible as an empty stub
> function. Currently none of the compilers are that clever :/
I won't hold my breath waiting for theoretical optimizations.
> This will break ARM64 I think, they don't HAVE_STATIC_CALL but do have
> CLANG_CFI, which means the above will end up being a runtime indirect
> call to a non-matching signature function.
>
> Now, I suppose we don't actually have this happen in current code by the
> simple expedient of not actually having any static_call_cond() usage
> outside of arch code.
>
> (/me git-grep's some and *arrrggh* trusted-keys)
>
> I really don't think we can do this though, must not promote CFI
> violations.
Ouch, so static_call_cond() and __static_call_return0() are broken today
on CFI_CLANG + arm64.
Some ideas:
1) Implement HAVE_STATIC_CALL for arm64. IIRC, this wasn't worth the
effort due to restricted branch ranges and CFI fun.
2) Create yet another "tier" of static call implementations, for
arches which can have the unfortunate combo of CFI_CLANG +
!HAVE_STATIC_CALL. CONFIG_ALMOST_DONT_HAVE_STATIC_CALL?
The arch can define ARCH_DEFINE_STATIC_CALL_NOP() which uses inline
asm to create a CFI-compliant NOP/BUG/whatever version of the
function (insert lots of hand-waving). Is the kcfi hash available
to inline asm at build time?
3) Use a jump label to bypass the static call instead of calling
__static_call_nop(). NOTE: I couldn't figure out how to do this
without angering the compiler, unless we want to change
static_call() back to the old-school interface:
static_call(foo, args...)
Is it Friday yet?
--
Josh
next prev parent reply other threads:[~2023-03-11 1:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-10 20:31 [RFC][PATCH 0/5] Improve static call NULL handling Josh Poimboeuf
2023-03-10 20:31 ` [RFC][PATCH 1/5] static_call: Make NULL static calls consistent Josh Poimboeuf
2023-03-10 20:59 ` Peter Zijlstra
2023-03-11 1:20 ` Josh Poimboeuf [this message]
2023-03-12 15:17 ` Peter Zijlstra
2023-03-13 15:08 ` Sean Christopherson
2023-03-13 17:48 ` Sami Tolvanen
2023-03-14 1:58 ` Josh Poimboeuf
2023-03-14 10:06 ` Peter Zijlstra
2023-03-10 20:31 ` [RFC][PATCH 2/5] static_call: Make NULL static calls return 0 Josh Poimboeuf
2023-03-10 20:31 ` [RFC][PATCH 3/5] static_call: Remove static_call_cond() and its usages Josh Poimboeuf
2023-03-10 20:31 ` [RFC][PATCH 4/5] static_call: Remove DEFINE_STATIC_CALL_RET0() and its uses Josh Poimboeuf
2023-03-10 20:31 ` [RFC][PATCH 5/5] x86/kvm: Simplify static call handling Josh Poimboeuf
2023-03-10 21:07 ` Sean Christopherson
2023-03-10 21:13 ` Steven Rostedt
2023-03-10 21:29 ` Sean Christopherson
2023-03-10 22:23 ` Josh Poimboeuf
2023-03-10 21:09 ` [RFC][PATCH 0/5] Improve static call NULL handling Steven Rostedt
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=20230311012004.vyc4kdlqjsv4zliw@treble \
--to=jpoimboe@kernel.org \
--cc=ardb@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=jbaron@akamai.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=seanjc@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
all inboxes | Powered by JetHome®