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

[Dave Hansen <dave.hansen@intel.com>]

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

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.