|
| ▲ | seangrogg 4 days ago | parent | next [-] |
| 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. |
| |
| ▲ | linuxnewb99 4 days ago | parent [-] | | Does it no longer suffer from TOCTOU? | | |
| ▲ | seangrogg 3 days ago | parent [-] | | 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. |
|
|
|
| ▲ | JoshTriplett 4 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | 1oooqooq 4 days ago | parent [-] | | wasn't the main issue about the asynchronous nature of the calls? | | |
| ▲ | JoshTriplett 4 days ago | parent [-] | | As far as I know, the new architecture still handles asynchronous offloading, it just uses a more secure-by-default means of doing so. |
|
|
|
| ▲ | stefanha 3 days ago | parent | prev [-] |
| 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. |
