From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Brendan Jackman <jackmanb@chromium.org>
Cc: linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
linux-security-module@vger.kernel.org,
Paul Renauld <renauld@google.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
James Morris <jmorris@namei.org>,
pjt@google.com, jannh@google.com, peterz@infradead.org,
rafael.j.wysocki@intel.com, keescook@chromium.org,
thgarnie@chromium.org, kpsingh@google.com,
paul.renauld.epfl@gmail.com,
Brendan Jackman <jackmanb@google.com>,
mathieu.desnoyers@efficios.com, rostedt@goodmis.org
Subject: Re: [RFC] security: replace indirect calls with static calls
Date: Fri, 5 Feb 2021 10:09:26 -0500 [thread overview]
Message-ID: <20210205150926.GA12608@localhost> (raw)
In-Reply-To: <20200820164753.3256899-1-jackmanb@chromium.org>
On 20-Aug-2020 06:47:53 PM, Brendan Jackman wrote:
> From: Paul Renauld <renauld@google.com>
>
> LSMs have high overhead due to indirect function calls through
> retpolines. This RPC proposes to replace these with static calls [1]
> instead.
>
> This overhead is especially significant for the "bpf" LSM which supports
> the implementation of LSM hooks with eBPF programs (security/bpf)[2]. In
> order to facilitate this, the "bpf" LSM provides a default nop callback for
> all LSM hooks. When enabled, the "bpf", LSM incurs an unnecessary /
> avoidable indirect call to this nop callback.
>
> The performance impact on a simple syscall eventfd_write (which triggers
> the file_permission hook) was measured with and without "bpf" LSM
> enabled. Activating the LSM resulted in an overhead of 4% [3].
>
> This overhead prevents the adoption of bpf LSM on performance critical
> systems, and also, in general, slows down all LSMs.
>
> Currently, the LSM hook callbacks are stored in a linked list and
> dispatched as indirect calls. Using static calls can remove this overhead
> by replacing all indirect calls with direct calls.
>
> During the discussion of the "bpf" LSM patch-set it was proposed to special
> case BPF LSM to avoid the overhead by using static keys. This was however
> not accepted and it was decided to [4]:
>
> - Not special-case the "bpf" LSM.
> - Implement a general solution benefitting the whole LSM framework.
>
> This is based on the static call branch [5].
Hi!
So I reviewed this quickly, and hopefully my understanding is correct.
AFAIU, your approach is limited to scenarios where the callbacks are
known at compile-time. It also appears to add the overhead of a
switch/case for every function call on the fast-path.
I am the original author of the tracepoint infrastructure in the Linux
kernel, which also needs to iterate on an array of callbacks. Recently,
Steven Rostedt pushed a change which accelerates the single-callback
case using static calls to reduce retpoline mitigation overhead, but I
would prefer if we could accelerate the multiple-callback case as well.
Note that for tracepoints, the callbacks are not known at compile-time.
This is where I think we could come up with a generic solution that
would fit both LSM and tracepoint use-cases.
Here is what I have in mind. Let's say we generate code to accelerate up
to N calls, and after that we have a fallback using indirect calls.
Then we should be able to generate the following using static keys as a
jump table and N static calls:
jump <static key label target>
label_N:
stack setup
call
label_N-1:
stack setup
call
label_N-2:
stack setup
call
...
label_0:
jump end
label_fallback:
<iteration and indirect calls>
end:
So the static keys would be used to jump to the appropriate label (using
a static branch, which has pretty much 0 overhead). Static calls would
be used to implement each of the calls.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2021-02-05 21:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-20 16:47 [RFC] security: replace indirect calls with static calls Brendan Jackman
2020-08-20 18:43 ` James Morris
2020-08-20 19:04 ` KP Singh
2020-08-20 21:45 ` Kees Cook
2020-08-24 14:09 ` Brendan Jackman
2020-08-24 14:33 ` Peter Zijlstra
2020-08-24 15:05 ` Brendan Jackman
2020-08-20 22:46 ` Casey Schaufler
2020-08-24 15:20 ` Brendan Jackman
2020-08-24 16:42 ` Casey Schaufler
2020-08-24 17:04 ` Brendan Jackman
2020-08-24 17:54 ` Casey Schaufler
2021-02-05 15:09 ` Mathieu Desnoyers [this message]
2021-02-05 15:40 ` Peter Zijlstra
2021-02-05 15:47 ` Mathieu Desnoyers
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=20210205150926.GA12608@localhost \
--to=mathieu.desnoyers@efficios.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jackmanb@chromium.org \
--cc=jackmanb@google.com \
--cc=jannh@google.com \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=kpsingh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul.renauld.epfl@gmail.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=rafael.j.wysocki@intel.com \
--cc=renauld@google.com \
--cc=rostedt@goodmis.org \
--cc=thgarnie@chromium.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).