Re: [PATCH bpf 26/81] bpf: Support BPF_REG_ARENA_SP in the verifier

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Wed, Oct 28, 2026 at 05:07 PM Kumar Kartikeya Dwivedi <memxor@gmail.com> wrote:
> I was not making a proposal. I don't even understand half the changes
> yet, 

let me try to explain stack-in-arena motivation.
Consider this code:

  struct Node<'a> { val: u32, next: Option<&'a Node<'a>> }

  static IN_RODATA: Node = Node { val: 3, next: None };

  fn sum(mut node: Option<&Node>) -> u32 {
      let mut sum = 0;
      while let Some(n) = node { sum += n.val; node = n.next; }
      sum
  }

  let heap = Box::new(Node { val: 20, next: Some(&IN_RODATA) });
  let local = Node { val: 100, next: Some(&*heap) };
  sum(Some(&local));

sum() reads the three nodes with the same two insns:

     local            heap          IN_RODATA
  +---------+      +---------+      +---------+
  | next  --+----->| next  --+----->| None    |
  | 100     |      | 20      |      | 3       |
  +---------+      +---------+      +---------+
       ^                ^                ^
       +----------------+----------------+
                        |
          w0 = *(u32 *)(r1 + 8)      n.val
          r1 = *(u64 *)(r1 + 0)      n.next

A rust reference doesn't say where the Node is.
It can be on stack, in heap, in rodata.
These two insns have to work for three different areas.

Hence the decision:

  step  memory               where  why
  ----  -------------------  -----  ---------------------------------------
  1     heap                 arena  The prog allocates it and links it with
                                    plain pointers.
  2     .data .bss .rodata   arena  heap.next is a load from arena, so it's
                                    a number. A number can be an address in
                                    arena and nothing else.
  3     address-taken local  arena  r1 is &local, then heap.next. One insn
                                    has one form in JIT.
  4     the rest of the      r10    The verifier doesn't track arena, and
        stack                       user space writes to it.


Decisions for .rodata:

  data                      where         
  ------------------------  ------------- 
  statics of Rust           arena         
                                          
  tables of functions       read-only map 
                                          
  strings for helpers and   read-only map 
  kfuncs                                  

The price: .rodata in arena is writable, and its values are not
constants for the verifier.

If .rodata stay as bpf array then above 2 insns won't work.

LLVM tldr:

  what      clang for C today     with the flag, for Rust
  --------  --------------------  -----------------------------------------
  statics   __arena variables:    statics: .addr_space.1 and
            .addr_space.1         .bss.addr_space.1
  locals    r10                   r10 or r12
  casts     by type: __arena      by origin: one cast for each pointer that
            pointers              doesn't come from the kernel

I hope it helps.