A crazy thought [LWN.net]

A crazy thought

Posted Jan 20, 2026 1:28 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
In reply to: A crazy thought by aszs
Parent article: Task-level io_uring restrictions

> Anyway, you can't call malloc or free in bpf programs

You absolutely can: https://docs.ebpf.io/linux/kfuncs/bpf_arena_alloc_pages/ Here's a mandatory LWN article about it: https://lwn.net/Articles/961941/

> hat said, a WASM-to-BPF byte code transpiler would be awesome, i'm surprised no one has made one yet.

The transpiler is trivial, but the runtime environments are too different for it to be useful.

to post comments

A crazy thought

Posted Jan 20, 2026 3:59 UTC (Tue) by aszs (subscriber, #50252) [Link] (7 responses)

> You absolutely can: https://docs.ebpf.io/linux/kfuncs/bpf_arena_alloc_pages/ Here's a mandatory LWN article about it: https://lwn.net/Articles/961941/

Sure, there's lots of ways to directly and indirectly allocate memory through bpf apis. But those pointers are tracked by the verifier to prevent unsafe access (use after free, pointer arithmetic, etc.). The wasm bytecode verifier doesn't do this, so any theoretical in-kernel wasm program couldn't safely access kernel memory directly.

A crazy thought

Posted Jan 20, 2026 6:14 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

> The wasm bytecode verifier doesn't do this

Yes, it does. WASM, just like eBPF, by construction can't access memory outside of its sandbox.

And just like in eBPF, WASM doesn't actually even _have_ pointers. It instead has indices in memory blocks, and they are always range-checked. Go on and try to read the spec: https://webassembly.github.io/spec/core/syntax/modules.ht...

It is very common for old C/C++ programs to re-create the malloc/free on top of a large pre-allocated block of memory in WASM and to use indexes to emulate the C/C++ pointers. And it's possible for C/C++ code in WASM to have out-of-bounds reads/writes, just like on the real hardware. So if you compile OpenSSL into WASM, it will still be vulnerable to a Heartbleed-like bug.

However, the out-of-bounds access in WASM still can NOT escape the memory blocks. They are compiled into index-based array operations, and they are always range-checked.

And of course, exactly the same scenario can happen in eBPF with arenas. The eBPF verifier won't do anything to help.

I just leaving this here

Posted Jan 20, 2026 7:20 UTC (Tue) by NHO (subscriber, #104320) [Link] (1 responses)

https://instatunnel.my/blog/the-wasm-breach-escaping-back...
No further comment

I just leaving this here

Posted Jan 20, 2026 7:35 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

In other words: bugs happen. Duh. Same for the eBPF, it also has had its share of CVEs.

The kernel developers themselves don't trust eBPF to be safe, so it's limited to the root user only.

A crazy thought

Posted Jan 20, 2026 14:13 UTC (Tue) by aszs (subscriber, #50252) [Link] (3 responses)

>> Yes, it does. WASM, just like eBPF, by construction can't access memory outside of its sandbox.

my first comment:

"WASM prevents code from accessing memory outside its sandbox but it doesn't provide memory safety within its sandbox. To provide safety guarantees similar to BPF you would need to make some pretty big changes to WASM. For example, see https://arxiv.org/abs/2208.13583"

We are literally going in circles. How would your in-kernel wasm jit handle the task_struct pointer returned by bpf_get_current_task_btf()? Or modifying xdp packets with apis like https://docs.ebpf.io/linux/helper-function/bpf_xdp_adjust... And do stuff like that safely without overhead?

A crazy thought

Posted Jan 20, 2026 18:48 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> We are literally going in circles. How would your in-kernel wasm jit handle the task_struct pointer returned by bpf_get_current_task_btf()?

Would you read the WASM spec, please? The task_struct will be modeled as a WASM structure type: https://webassembly.github.io/spec/core/syntax/types.html... It's accessible via _references_ only ( https://webassembly.github.io/spec/core/syntax/types.html... ):

> Reference types are opaque, meaning that neither their size nor their bit pattern can be observed. Values of reference type can be stored in tables but not in memories.

It will NOT be accessible using pointer operations from any memory blocks. That's how browsers expose complex objects into the WASM world.

Just like in eBPF (does that phrase sound familiar by now?).

> And do stuff like that safely without overhead?

Yes. Just like in eBPF.

Again, this is not something theoretical or exotic. That's how browsers work RIGHT NOW.

A crazy thought

Posted Jan 21, 2026 17:35 UTC (Wed) by notriddle (subscriber, #130608) [Link] (1 responses)

It’s probably worth pointing out that the features you’re talking about are less than a year old. https://webassembly.org/news/2025-09-17-wasm-3.0/

Not necessarily a problem, but it does mean that the idea of wasm being “battle-tested” is wrong. The features you think they should rely on are new.

A crazy thought

Posted Jan 21, 2026 18:41 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

The typed references are new, but even the first version of WASM had something similar: https://www.w3.org/TR/2019/REC-wasm-core-1-20191205/#exte...

External types were represented as tables and functions with similar limitations, they were treated as opaque objects without any ways to get to their exact binary representation (never mind modify them).