Making io_uring pervasive in QEMU [pdf](vmsplice.net)
vmsplice.net
Making io_uring pervasive in QEMU [pdf]
https://vmsplice.net/~stefan/stefanha-kvm-forum-2025.pdf
9 comments
If you want to watch the talk that these are the slides for, it's now up on youtube along with the other KVM Forum talks: https://youtu.be/gSB5sn3ZN3w
How is security looking with io_uring these days? I've been wary of it since https://security.googleblog.com/2023/06/learnings-from-kctf-...
I've only dabbled, so I'm happy to have people with more linux-side knowledge to call me out on any inaccuracies here, but...
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.
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.
Does it no longer suffer from TOCTOU?
I don't consider myself fully qualified to speak to this, so please take it with a grain of salt.
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.
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.
Security with io_uring is great these days. Many years ago it moved away from the original architecture that led to several security issues; its current architecture is no more prone to security issues than any other part of the kernel.
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.
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.
wasn't the main issue about the asynchronous nature of the calls?
As far as I know, the new architecture still handles asynchronous offloading, it just uses a more secure-by-default means of doing so.
I'm the presenter of the talk, but not an io_uring kernel developer or security expert.
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.
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.