From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Yeoreum Yun <yeoreum.yun@arm.com>,
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, 19 Feb 2026 18:50:24 -0800 [thread overview]
Message-ID: <CAADnVQJuYDgbwvZa9zuUXcPoHRp25n5NYutbEsv6F-NzeK4oDg@mail.gmail.com> (raw)
In-Reply-To: <9c7a5db754143f59bdb2129616d2a23495d4b3b9.camel@HansenPartnership.com>
On Mon, Feb 16, 2026 at 6:27 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Fri, 2026-02-13 at 13:37 -0800, Alexei Starovoitov wrote:
> > 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:
> [...]
> > > > > 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.
>
> That's a bit of a short sighted attitude and also you're looking at it
> in the wrong way: hardware, correctly designed, should always be
> looking at ways to help software. eBPF may not "need" this in the same
> way qemu doesn't need the VMX accelerations ... it's just more secure
> and efficient when they're in use. After all, if the kernel had said
> "no" to VMX in 2006, KVM would never have existed, we'd have been stuck
This is a false analogy. Virtualization extensions were added
because virtualization software already existed and had shortcomings
that CPU designers wanted to address.
Here pkey was added to differentiate one ISA to another and
now cpu folks are desperately looking for a use case.
Maybe it exists, but it's definitely not bpf.
prev parent reply other threads:[~2026-02-20 2:50 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
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 [this message]
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=CAADnVQJuYDgbwvZa9zuUXcPoHRp25n5NYutbEsv6F-NzeK4oDg@mail.gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=James.Bottomley@hansenpartnership.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 \
--cc=yeoreum.yun@arm.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