Making Io_uring Pervasive in Qemu [pdf]
Posted4 months agoActive4 months ago
vmsplice.netTechstory
calmmixed
Debate
20/100
Io_uringQemuLinux Kernel
Key topics
Io_uring
Qemu
Linux Kernel
The presentation discusses making io_uring pervasive in QEMU, a popular open-source emulator, and the discussion revolves around the technical details and security concerns of io_uring.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
3h
Peak period
2
2-4h
Avg / period
1.8
Key moments
- 01Story posted
Sep 11, 2025 at 2:32 PM EDT
4 months ago
Step 01 - 02First comment
Sep 11, 2025 at 5:18 PM EDT
3h after posting
Step 02 - 03Peak activity
2 comments in 2-4h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 12, 2025 at 2:28 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45214672Type: storyLast synced: 11/20/2025, 3:32:02 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
io_uring is effectively as "secure" as any other syscall unto itself. The issue is that the mechanism by which io_uring makes its syscalls as part of its submission/completion queues means that those underlying syscalls can't be filtered by seccomp. The real question is your security posture.
If you're writing a hypervisor that's intended to partition resources between underlying users in a secure fashion, the ability for io_uring to bypass seccomp is largely a non-starter. But if you own the machine and you just want to run an application on it (i.e. an HTTP server that uses io_uring for file/network io) you should largely be in the clear.
From what I gather it seems like you could potentially create scenarios where TOCTOU is indeed a problem, but in considering the situations where it could come up I do feel like all my ideas are somewhat contrived in nature. And even when noodling on it I very much get the feeling that I return to my previous statement: consider what you're building. I think that the potential for TOCTOU could potentially compromise a hypervisor's security (i.e. letting an arbitrary number of user on a system make arbitrary io_uring calls) and even if I couldn't demonstrate how that could be weaponized I would avoid it. However, if you're writing an application that's going to do a read(2) or something, I don't see TOCTOU being a uniquely io_uring problem.
For context, the original architecture involved having privileged kernel-side offload processing that had to carefully drop privileges each time it did something on behalf of the userspace process. As you can imagine, that fail-insecure architecture was heavily prone to security holes.
io_uring got rid of that architecture years ago, in favor of running with the permissions of the userspace process. With that change, there's no longer any reason to consider io_uring any less secure than the rest of the kernel.
The io_uring implementation is complex and the number of lines of code is non-trivial. On the other hand, as code matures and the number of bugs being reported falls, the trade-off between functionality gained and risk of security issues changes. More people will decide to use io_uring as time passes. People already rely on much larger and more complex subsystems like the network stack or file systems.