Re: [LSF/MM/BPF TOPIC] eBPF isolation with pkeys

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Fri, Feb 13, 2026 at 2:10 AM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
>
> Hi Alexei,
>
> > On Thu, Feb 12, 2026 at 10:03 AM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > >
> > > Hi Alexei,
> > >
> > > > On Thu, Feb 12, 2026 at 8:24 AM Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I would like to propose the topic of eBPF isolation with pkeys at the
> > > > > upcoming LSF/MM/BPF summit.
> > > > >
> > > > >
> > > > > Background
> > > > > ==========
> > > > >
> > > > > Today, eBPF programs provide powerful capabilities to extend kernel
> > > > > functionality without requiring modifications to the kernel itself.
> > > > > These capabilities are largely enabled by the eBPF verifier, which
> > > > > enforces memory safety and other constraints to protect the kernel.
> > > > >
> > > > > However, vulnerabilities in the verifier have repeatedly demonstrated that
> > > > > eBPF programs can also become a serious attack surface.  In several cases,
> > > > > flaws in verifier logic have allowed malicious eBPF programs to bypass
> > > > > safety guarantees and compromise kernel security.
> > > >
> > > > eBPF was restricted to root for many years, so the above is simply not true.
> > > >
> > > > > Representative CVEs include:
> > > > >
> > > > >      - CVE-2020-8835   [1]
> > > > >      - CVE-2021-3490   [2]
> > > > >      - CVE-2022-23222  [3]
> > > > >      - CVE-2023-2163   [4]
> > > >
> > > > None of them are security issues. They're just bugs.
> > > > Like all those found by syzbot.
> > > >
> > > > > An RFC series is planned for around Q2 2026, and the experimental
> > > > > implementations for eBPF isolation with pkey and pkey-aware memory
> > > > > allocators have already been completed internally.  Using these
> > > > > implementations, we verified that eBPF programs running under isolation
> > > > > successfully execute several sched_ext applications provided by
> > > > > tools/sched_ext, as well as some bpf kselftest cases.
> > > >
> > > > The stated goal is wrong, hence not interested in patches
> > > > or discussion at lsfmm.
> > > >
> > > > arm has a nice hw feature. Sure, but this is not a place to apply it.
> > >
> > > That is correct — this is a verifier bug.
> > > However, the concern is that such a bug can lead to a security incident.
> > > Not only root, but also users with CAP_BPF who are allowed to
> > > load eBPF programs could potentially trigger additional security issues
> > > through such bugs.
> >
> > Again. They are not security issues. cap_bpf is effectively root.
> > Just like cap_perfmon in tracing space is a root.
>
> The argument is not about whether the verifier bug is a security issue
> per se.  The point is that relying solely on privilege boundaries
> (e.g., root-only loading) does not eliminate the impact of a verifier bug.
> Therefore, leveraging hardware isolation to further constrain
> the blast radius is a defense-in-depth measure.

I hate the reasoning that bpf somehow needs this hw feature.
It's not. Look for other use cases for pkey.