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

[Yeoreum Yun <yeoreum.yun@arm.com>]

Hi Dave,

> BTW, one high-level thing: what you're talking about here really is a
> kind of hardening or kernel self-protection. It's in the spirit of Kees
> Cook's work: how can kernel security be resilient even in the face of
> kernel bugs and attackers exploiting those bugs?
>
> Those who buy into the idea of Kees's work will likely agree with the
> premise of this patch set. Those that don't, won't. :)

Yes exactly. But one of my small wish is most people view this positively...

>
> On 2/12/26 09:14, Yeoreum Yun wrote:
> >>> To that end, this discussion introduces a set of new allocator APIs and
> >>> explores more extensible API designs:
> >>>
> >>>   - kmalloc_pkey series
> >>>   - vmalloc_pkey series
> >>>   - alloc_percpu_pkey series
> >>
> >> It all sounds fun, but this doesn't exactly seem very generic. The memory
> >> that sched_ext needs to access is super different from, say, what a
> >> socket-filtering eBPF program would need.
> >>
> >> So this doesn't seem to be likely to be true "eBPF isolation" as much as
> >> sched_ext+eBPP isolation.
> >
> > Our current isolation model focuses on restricting writes and execution.
> > Therefore, if we allocate only the memory that eBPF programs must write
> > directly with a separate pkey (e.g., packet data or sock),
> > it seems to me that socket-filtering programs could also benefit from
> > the same isolation.
> This means that subsystems using eBPF need to allocate their data
> structures separately, or at least in a pkey-aware manner. They either
> need to declare the memory at allocation time, or need to be able to pay
> the cost (and the collateral damage) of changing its pkey after allocation.
>
> This _might_ be doable for the scheduler. It probably has a limited set
> of things that get written to. Most of it is statically allocated.
>
> Networking isn't my strong suit, but packet memory seems rather
> dynamically allocated and also needs to be written to by eBPF programs.
> I suspect anything that slows packet allocation down by even a few
> cycles is a non-starter.
>
> IMNHO, _any_ approach to solving this problem that start with: we just
> need a new allocator or modification to existing kernel allocators to
> track a new memory type makes it a dead end. Or, best case, a very
> surgical, targeted solution.

TBH, I think there is no difference for a _memory_ usage between
Network packet and scheduler since most of BPF program uses
"MAPs" and this is needed to be written directly by them and
"MAPs" are always allocated dynamically not statically and uses
existing allocators' feature.

IMHO, I think it would be better to make existed memory allocator
aware pkey than make a new allocator since the there is no difference
except pkey-aware with existing allocator (and I think
this would make a more code duplication and add more complexity).

Thus, I would like to discuss with the way to extension of
existing allocators first.


--
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.