> He also wants to see about adding better debugging capabilities to arenas; arenas may obviate the need to fight with the verifier, but that also means that there can be ordinary memory-safety problems that, while not a threat to the kernel, still need to be found and fixed.

Once you have a number of components using raw pointers into arenas, you introduce all the same memory safety problems that plague normal C programs. When BPF programs start doing things like scheduling processes and making access control decisions, these bugs can become exploitable.

> make BPF C as easy to write as normal C

If normal C is easy to write, it's unsafe. If C is safe, it's neither normal nor easy to write. Better to make it a non-goal and provide dedicated map types for each data storage need. If the BPF program is complex enough that it needs to be able to malloc from an arena, the program should be a userspace program with a BPF interface. Otherwise, in the limit, the BPF world becomes just another *kind* of userspace, albeit with isolation enforced via code analysis instead of page tables and hardware privilege levels.

Instead of making BPF look more like userspace, I'd make it easier to integrate BPF *with* userspace, e.g. using io_uring to help BPF programs offload state management and policy enforcement to userspace helpers.