io_uring [LWN.net]

io_uring

Posted Jun 5, 2026 14:45 UTC (Fri) by josh (subscriber, #17465)
Parent article: Moving beyond fork() + exec()

I've said this before (and have given a talk on it): I think the right mechanism for "actions" is an io_uring. Create a new empty process, run a ring in it to do things like receive/install file descriptors, end the ring with one or more attempts at exec, if you hit the end of the ring without an exec then the process gets SIGKILLed.

I do think it makes sense to combine that with the "spawn template" mechanism somehow, insofar as one might want to load an ELF once and then repeatedly execute it (e.g. make invoking gcc).

io_uring

Posted Jun 5, 2026 15:32 UTC (Fri) by bluca (subscriber, #118303) [Link] (6 responses)

One major difference is that there would be no seccomp support, which for something that allows spawning processes would be a pretty major shortcoming. I'm not up to date on the generic LSM story aside from that, but at some point it I think it basically boiled down to "block iouring" or "allow iouring" and that was it, maybe things have moved on that front though

io_uring

Posted Jun 5, 2026 15:41 UTC (Fri) by krisman (subscriber, #102057) [Link] (5 responses)

Not true anymore. We now have per-operation bpf-based filtering in io_uring.

io_uring

Posted Jun 5, 2026 15:55 UTC (Fri) by bluca (subscriber, #118303) [Link] (2 responses)

So still no seccomp, and requires its own bespoke filtering? As a userspace developer making heavy use of pidfd_spawn I'd much rather have a normal syscall based approach, like fsconfig(). Much nicer, and integrates much better with the existing sandboxing ecosystem. fsconfig/opentree/movemount/etc are a really nice family of APIs, well designed and pleasant to use.

io_uring

Posted Jun 5, 2026 16:09 UTC (Fri) by josh (subscriber, #17465) [Link] (1 responses)

No matter what filtering mechanism you use, operations in io_uring do not map 1:1 to syscalls. I think the BPF-based filtering in io_uring is a reasonable mapping of filtering to the concepts of io_uring. Using seccomp would still require substantially adapting seccomp; existing filters would not Just Work.

io_uring

Posted Jun 7, 2026 7:13 UTC (Sun) by daandemeyer (subscriber, #163201) [Link]

Uring has its own filtering mechanism these days. Not quite seccomp but close. But I doubt any userspace has plumbed it through already. Will take years likely before uring is removed from existing seccomp profiles.

io_uring

Posted Jun 7, 2026 3:30 UTC (Sun) by DemiMarie (subscriber, #164188) [Link]

Can that be enforced by a sandboxing tool and automatically applied to all rings created by a child process?

Until Google enables io_uring for third-party apps on Android I will stay skeptical.

io_uring filtering

Posted Jun 7, 2026 3:30 UTC (Sun) by DemiMarie (subscriber, #164188) [Link]

Can the filtering be enforced by a sandboxing tool and automatically applied to all rings created by a child process? Does it require eBPF or only cBPF?

Until Google enables io_uring for third-party apps on Android I will stay skeptical

io_uring

Posted Jun 5, 2026 17:49 UTC (Fri) by calvin (subscriber, #168398) [Link] (3 responses)

Why not go further? Be able to spawn a process with an empty set of FDs, address space, etc, then load an executable yourself. This would also allow for moving more exec() loader responsibilities into userspace.

io_uring

Posted Jun 5, 2026 19:56 UTC (Fri) by josh (subscriber, #17465) [Link]

That would work in many cases, but you still need to handle exec in the kernel for suid or similar.

That said, that does not need to be the high performance case; it would be fine to have a userspace mechanism for everything and have it just not work when escalating privileges.

io_uring

Posted Jun 6, 2026 4:53 UTC (Sat) by IAmLiterallyABee (subscriber, #144892) [Link]

That's basically how Fuchsia works

io_uring

Posted Jun 8, 2026 19:20 UTC (Mon) by kreijack (guest, #43513) [Link]

> Why not go further? Be able to spawn a process with an empty set of FDs, address space, etc, then load an executable yourself. This would also allow for moving more exec() loader responsibilities into userspace.

How it could be useful: with an empty list of FD, there is no way to communicate; without any memory sharing, all the parameter (like the executable path, arguments) has to be "hard coded" in the code...

Unfortunately, the true is that the parent and the child have to have something in common (at least some file descriptors to communicate). But other things can be shared, like shared memory , privileges....

I am curious to see some numbers about the cost of fork+exec vs the zygote patter, just to understand if it is a common problem, or it is only a problem of some edge case.

io_uring

Posted Jun 5, 2026 19:36 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

You want to extend io_uring is some “special way”… Why? What would it buy you? Do you really spawn so many processes that normal syscalls are not enough?

Just execute the code that would perform you damn template (and yes, this very much includes io_uring if you really need to) using existing mechanisms.

No need to change anything in kernel at all, everything can be done from the userspace.

io_uring

Posted Jun 5, 2026 19:58 UTC (Fri) by josh (subscriber, #17465) [Link]

I am suggesting adding a system call to load an executable for subsequent repeated reuse, and then separately providing bindings for that system call to io_uring. It would be available either way, it would just be faster via io_uring.