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.
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.
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.
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.
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.
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.
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.
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.