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

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

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.