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

▲

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.