From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: lsf-pc <lsf-pc@lists.linux-foundation.org>,
linux-mm <linux-mm@kvack.org>, bpf <bpf@vger.kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
david@kernel.org, ryan.roberts@arm.com, kevin.brodsky@arm.com,
sebastian.osterlund@intel.com,
Dave Hansen <dave.hansen@linux.intel.com>,
Rick Edgecombe <rick.p.edgecombe@intel.com>
Subject: Re: [LSF/MM/BPF TOPIC] eBPF isolation with pkeys
Date: Thu, 12 Feb 2026 18:01:46 +0000 [thread overview]
Message-ID: <aY4Vipl+4rGa+u6D@e129823.arm.com> (raw)
In-Reply-To: <CAADnVQ+D7v+sGFFyTfSxFSEEcnGV111NeSaVtASYHfP-mDnV4w@mail.gmail.com>
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.
The proposed isolation mechanism is intended as a safeguard to minimize
the impact of security incidents that could arise from
bugs in the eBPF verifier. For that reason, I believe LSF/MM would be
an appropriate venue to discuss this approach and apply pkeys to here.
Am I overlooking anything?
--
Sincerely,
Yeoreum Yun
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
next prev parent reply other threads:[~2026-02-12 18:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-12 16:22 Yeoreum Yun
2026-02-12 16:36 ` Dave Hansen
2026-02-12 17:14 ` Yeoreum Yun
2026-02-12 18:14 ` Dave Hansen
2026-02-16 9:57 ` Yeoreum Yun
2026-02-12 17:44 ` Alexei Starovoitov
2026-02-12 18:01 ` Yeoreum Yun [this message]
2026-02-12 18:37 ` Alexei Starovoitov
2026-02-13 10:08 ` Yeoreum Yun
2026-02-13 21:37 ` Alexei Starovoitov
2026-02-16 14:27 ` James Bottomley
2026-02-20 2:50 ` Alexei Starovoitov
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=aY4Vipl+4rGa+u6D@e129823.arm.com \
--to=yeoreum.yun@arm.com \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=kevin.brodsky@arm.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=rick.p.edgecombe@intel.com \
--cc=ryan.roberts@arm.com \
--cc=sebastian.osterlund@intel.com \
/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