linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: KP Singh <kpsingh@kernel.org>,
	linux-security-module@vger.kernel.org, bpf@vger.kernel.org
Cc: paul@paul-moore.com, keescook@chromium.org,
	casey@schaufler-ca.com, song@kernel.org, daniel@iogearbox.net,
	ast@kernel.org, renauld@google.com
Subject: Re: [PATCH v5 0/5] Reduce overhead of LSMs with static calls
Date: Mon, 02 Oct 2023 13:06:15 +0200	[thread overview]
Message-ID: <5a56953293ae90a1e20a414a44f45a94ee971792.camel@redhat.com> (raw)
In-Reply-To: <20230928202410.3765062-1-kpsingh@kernel.org>

On Thu, 2023-09-28 at 22:24 +0200, KP Singh wrote:
> # Background
> 
> LSM hooks (callbacks) are currently invoked as indirect function calls. These
> callbacks are registered into a linked list at boot time as the order of the
> LSMs can be configured on the kernel command line with the "lsm=" command line
> parameter.
> 
> Indirect function calls have a high overhead due to retpoline mitigation for
> various speculative execution attacks.
> 
> Retpolines remain relevant even with newer generation CPUs as recently
> discovered speculative attacks, like Spectre BHB need Retpolines to mitigate
> against branch history injection and still need to be used in combination with
> newer mitigation features like eIBRS.
> 
> This overhead is especially significant for the "bpf" LSM which allows the user
> to implement LSM functionality with eBPF program. In order to facilitate this
> the "bpf" LSM provides a default callback for all LSM hooks. When enabled,
> the "bpf" LSM incurs an unnecessary / avoidable indirect call. This is
> especially bad in OS hot paths (e.g. in the networking stack).
> This overhead prevents the adoption of bpf LSM on performance critical
> systems, and also, in general, slows down all LSMs.
> 
> Since we know the address of the enabled LSM callbacks at compile time and only
> the order is determined at boot time, the LSM framework can allocate static
> calls for each of the possible LSM callbacks and these calls can be updated once
> the order is determined at boot.
> 
> This series is a respin of the RFC proposed by Paul Renauld (renauld@google.com)
> and Brendan Jackman (jackmanb@google.com) [1]
> 
> # Performance improvement
> 
> With this patch-set some syscalls with lots of LSM hooks in their path
> benefitted at an average of ~3% and I/O and Pipe based system calls benefitting
> the most.
> 
> Here are the results of the relevant Unixbench system benchmarks with BPF LSM
> and SELinux enabled with default policies enabled with and without these
> patches.
> 
> Benchmark                                               Delta(%): (+ is better)
> ===============================================================================
> Execl Throughput                                             +1.9356
> File Write 1024 bufsize 2000 maxblocks                       +6.5953
> Pipe Throughput                                              +9.5499
> Pipe-based Context Switching                                 +3.0209
> Process Creation                                             +2.3246
> Shell Scripts (1 concurrent)                                 +1.4975
> System Call Overhead                                         +2.7815
> System Benchmarks Index Score (Partial Only):                +3.4859

FTR, I also measure a ~3% tput improvement in UDP stream test over
loopback.

@KP Singh, I would have appreciated being cc-ed here, since I provided
feedback on a previous revision (as soon as I learned of this effort).

Cheers,

Paolo


  parent reply	other threads:[~2023-10-02 11:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-28 20:24 [PATCH v5 0/5] Reduce overhead of LSMs with static calls KP Singh
2023-09-28 20:24 ` [PATCH v5 1/5] kernel: Add helper macros for loop unrolling KP Singh
2023-09-28 20:24 ` [PATCH v5 2/5] security: Count the LSMs enabled at compile time KP Singh
2023-09-29  0:37   ` Kees Cook
2023-09-28 20:24 ` [PATCH v5 3/5] security: Replace indirect LSM hook calls with static calls KP Singh
2023-09-30 16:13   ` kernel test robot
2023-09-30 20:40     ` Kees Cook
2023-10-04  0:09       ` KP Singh
2023-09-28 20:24 ` [PATCH v5 4/5] bpf: Only enable BPF LSM hooks when an LSM program is attached KP Singh
2023-10-05  8:09   ` Jiri Olsa
2023-10-05 13:26     ` KP Singh
2023-10-05 13:27       ` KP Singh
2023-10-05 13:52         ` Jiri Olsa
2023-10-05 16:07           ` KP Singh
2023-10-06  7:27             ` Jiri Olsa
2023-10-06  9:05               ` Jiri Olsa
2023-10-06 10:57                 ` KP Singh
2023-10-06 18:32                   ` KP Singh
2023-09-28 20:24 ` [PATCH v5 5/5] security: Add CONFIG_SECURITY_HOOK_LIKELY KP Singh
2023-09-29  0:38   ` Kees Cook
2023-09-29  0:41 ` [PATCH v5 0/5] Reduce overhead of LSMs with static calls Kees Cook
2023-10-02 11:06 ` Paolo Abeni [this message]
2023-10-02 11:09   ` KP Singh
2023-10-02 13:27     ` Paolo Abeni

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=5a56953293ae90a1e20a414a44f45a94ee971792.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=casey@schaufler-ca.com \
    --cc=daniel@iogearbox.net \
    --cc=keescook@chromium.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=renauld@google.com \
    --cc=song@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).