[LSF/MM/BPF TOPIC] What's more in BPF+LSM (KRSI)?

[KP Singh <kpsingh@chromium.org>]

What's more in BPF+LSM (KRSI)?
============================

The basics for the KRSI patches are being reviewed currently on the
mailing list:

   https://lore.kernel.org/bpf/20200123152440.28956-1-kpsingh@chromium.org/T/#t

Here are some proposed discussions topics:

RCU/Preemption + BPF_PROG_TYPE_LSM
----------------------------------

With the new Trampoline based implementation it's ~trivial~ to enable
preemption and remove the RCU read side critical section when
executing the JIT'ed program. This is required, atleast, for the
following 2 use-cases:

1. Non-Atomic Helpers

Getting remote user pages (get_user_pages_remote) for argv and
environment variable based policies needs to run in non-atomic context
(because it might trigger a page fault).

2. BTF __rcu pointer access

Since BPF_PROG_TYPE_LSM uses BTF, it can access valid struct members.
However, if such a member is "__rcu" pointer, there are no
checks/helpers to "properly" access it.

Ideas:

 Here are a couple of options we can discuss:

* Update the JIT logic to guard helper calls with RCU critical
  sections or wrap pointer access with rcu_deference automatically
  when a BPF program calls it. This might still be restrictive if a
  user wants to use rcu_deference_raw etc for pointer values.
  It's also going to be tricky to determine the scope of the
  critical section beyond adding RCU calls before and after a helper
  call or a pointer dereference.

* Just track and verify whether the BPF program calls the right
  helpers (say bpf_rcu_*) This is likely to be more feasible and
  similar to the spin lock tracking already done by the verifier.

If sleepable BPF becomes a thing, one can dump argument pages in 4K
chunks to the perf events buffer there by saving a large amount of
memory which is currently required to "pin" these pages in a preamble
so that they are accessible in an atomic context in the program.

Security Blobs using BPF programs
---------------------------------

Security blobs must be set at init to provide any real guarantees to
any API that uses security blobs. KRSI currently plans to have static
hooks for blobs but one can think of loading a restricted set of
BPF programs purely to enable security blobs at boot time.
This would make the overall code more flexible.

Userspace eco-system
--------------------

As we bring KRSI closer to mainline, it's worth thinking of the
userspace ecosystem. e.g. can we add BPF capabilities to the likes of
auditctl and use bpftrace for KRSI programs?

- KP