bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: KP Singh <kpsingh@kernel.org>
To: 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, jannh@google.com
Subject: [PATCH v2 0/5] Reduce overhead of LSMs with static calls
Date: Fri, 16 Jun 2023 02:04:36 +0200	[thread overview]
Message-ID: <20230616000441.3677441-1-kpsingh@kernel.org> (raw)

# 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

In the best case, some syscalls like eventfd_create benefitted to about ~10%.
The full analysis can be viewed at https://kpsingh.ch/lsm-perf

[1] https://lore.kernel.org/linux-security-module/20200820164753.3256899-1-jackmanb@chromium.org/


# BPF LSM Side effects

Patch 4 of the series also addresses the issues with the side effects of the
default value return values of the BPF LSM callbacks and also removes the
overheads associated with them making it deployable at hyperscale.

# v1 -> v2 (based on linux-next, next-20230614)

- Incorporated suggestions from Kees
- Changed the way MAX_LSMs are counted from a binary based generator to a clever header.
- Add CONFIG_SECURITY_HOOK_LIKELY to configure the likelihood of LSM hooks.

(Note on avaialability: I won't be able to reply / rev the series for the next couple of weeks)

KP Singh (5):
  kernel: Add helper macros for loop unrolling
  security: Count the LSMs enabled at compile time
  security: Replace indirect LSM hook calls with static calls
  bpf: Only enable BPF LSM hooks when an LSM program is attached
  security: Add CONFIG_SECURITY_HOOK_LIKELY

 include/linux/bpf.h       |   1 +
 include/linux/bpf_lsm.h   |   5 +
 include/linux/lsm_count.h | 131 +++++++++++++++++++++++++
 include/linux/lsm_hooks.h |  81 ++++++++++++++--
 include/linux/unroll.h    |  36 +++++++
 kernel/bpf/trampoline.c   |  29 +++++-
 security/Kconfig          |  11 +++
 security/bpf/hooks.c      |  25 ++++-
 security/security.c       | 197 +++++++++++++++++++++++++-------------
 9 files changed, 438 insertions(+), 78 deletions(-)
 create mode 100644 include/linux/lsm_count.h
 create mode 100644 include/linux/unroll.h

-- 
2.41.0.162.gfafddb0af9-goog


             reply	other threads:[~2023-06-16  0:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-16  0:04 KP Singh [this message]
2023-06-16  0:04 ` [PATCH v2 1/5] kernel: Add helper macros for loop unrolling KP Singh
2023-06-16  0:04 ` [PATCH v2 2/5] security: Count the LSMs enabled at compile time KP Singh
2023-06-16  0:38   ` Casey Schaufler
2023-06-16 22:27     ` Andrii Nakryiko
2023-09-16  0:54       ` KP Singh
2023-06-16  0:04 ` [PATCH v2 3/5] security: Replace indirect LSM hook calls with static calls KP Singh
2023-06-16  1:05   ` Casey Schaufler
2023-06-17 15:09     ` KP Singh
2023-06-16  3:41   ` kernel test robot
2023-06-16 21:09   ` kernel test robot
2023-06-17 15:39     ` KP Singh
2023-06-20 21:53   ` Kees Cook
2023-06-16  0:04 ` [PATCH v2 4/5] bpf: Only enable BPF LSM hooks when an LSM program is attached KP Singh
2023-06-16  0:04 ` [PATCH v2 5/5] security: Add CONFIG_SECURITY_HOOK_LIKELY KP Singh
2023-06-16  1:14   ` Casey Schaufler
2023-06-17 15:11     ` KP Singh
2023-06-20 20:58   ` Kees Cook
2023-09-18 13:27     ` KP Singh
2023-09-18 13:55   ` Paul Moore
2023-09-18 16:28     ` KP Singh

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=20230616000441.3677441-1-kpsingh@kernel.org \
    --to=kpsingh@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=casey@schaufler-ca.com \
    --cc=daniel@iogearbox.net \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.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).