io_uring shouldn't be used yet, though. Its ABI is not stable (not even talking about liburing) and its performance characteristics are not figured out yet.
It's not super well tested and so far only gives reliable speedups for Filesystem operations.
There's a lot more work to be done on it before anyone should be using it in production, IMO.
There's also alot of security implications. The security credentials of an io_uring are established at creation time. So daemon services that do something like:
/* setup event loop */
io_uring_create();
...
/* bind ports, do other privileged initializations */
...
/* drop privileges */
setuid("unshared-unique-uid");
/* submit file open */
write_open_request_to_uring(tainted_path)
can silently become exploit vectors because now the functional open() can occur with root permissions instead of the process' current identity. io_uring is basically just a threaded work dispatcher, except it uses threads created in the kernel, with the main thread dequeuing operations from a shared byte buffer and optimistically attempting every operation. All these process semantics are totally hidden and non-obvious.
I think there are provisions for specifying credentials at submission time, and some tentative plans for dealing with passing the io_uring handle across processes, but neither address this fundamental issue, which is far more prevalent than the esoteric concerns currently being addressed.
These known and unknown future pitfalls are why Kees Cook doesn't really like the idea at all. I/O libraries that offer the potential for easily or even transparently switching over to io_uring definitely won't help matters. And all the fanciest programming language type safety in the world won't save you.
Expect several years of easy remote exploits down the road...
NB: I could be mistaken on some points. Please feel free to correct me.
Has this problem been filed as an issue with Jens Axboe? I would like to hear his response to it. https://github.com/axboe/liburing I believe.
> There's also alot of security implications
To be clear, this is liburing, NOT the io_uring syscalls that I would assume Tokio would opt for.
> io_uring is basically just a threaded work dispatcher
Only under SQPOLL mode. This isn't an inherent property of io_uring.
> All these process semantics are totally hidden and non-obvious
Again, only if you use liburing. The syscalls make this abundantly clear, as there's no other way to program for them.
> These known and unknown future pitfalls
The problem isn't with io_uring here, the problem is with the over-saturation of the development world with people who do not care about doing things correctly or safely but instead quickly and cost-effectively.
This is not unique to io_uring, however. Let's not throw the baby out with the bathwater.
> And all the fanciest programming language type safety in the world won't save you.
I agree whole-heartedly.
> Expect several years of easy remote exploits down the road...
I would rather be interested to see which sidechannels were attacked in order to take advantage of io_uring. Those vulns are going to lay with the framework implementors and the users of frameworks, less with io_uring. But I understand the concern.
> The security credentials of an io_uring are established at creation time.
Well, the security credentials of a file descriptor are established at ```open()``` time. Is this really so different?
Running through the list of io_uring opcodes, only two of them work on ```char*``` paths: IORING_OP_OPENAT and IORING_OP_OPENAT2, which were added to io_uring after it was introduced. All the rest operate solely upon already-opened file descriptors, and POSIX doesn't do any permission checks for operations on already-open descriptors anyways.
It sounds like the issue you mention was an oversight when IORING_OP_OPENAT(2) were added. The easy, and retroactively safe, fix is to forbid these opcodes on submission queues by default, unless the submission queue was opened with a special flag whose name includes a scary warning -- something like IOURING_I_WILL_NOT_SETUID_WITHOUT_CLOSING_THIS_RING_FIRST.
4 comments
[ 1.9 ms ] story [ 22.3 ms ] threadIt's not super well tested and so far only gives reliable speedups for Filesystem operations.
There's a lot more work to be done on it before anyone should be using it in production, IMO.
I think there are provisions for specifying credentials at submission time, and some tentative plans for dealing with passing the io_uring handle across processes, but neither address this fundamental issue, which is far more prevalent than the esoteric concerns currently being addressed.
These known and unknown future pitfalls are why Kees Cook doesn't really like the idea at all. I/O libraries that offer the potential for easily or even transparently switching over to io_uring definitely won't help matters. And all the fanciest programming language type safety in the world won't save you.
Expect several years of easy remote exploits down the road...
NB: I could be mistaken on some points. Please feel free to correct me.
> There's also alot of security implications
To be clear, this is liburing, NOT the io_uring syscalls that I would assume Tokio would opt for.
> io_uring is basically just a threaded work dispatcher
Only under SQPOLL mode. This isn't an inherent property of io_uring.
> All these process semantics are totally hidden and non-obvious
Again, only if you use liburing. The syscalls make this abundantly clear, as there's no other way to program for them.
> These known and unknown future pitfalls
The problem isn't with io_uring here, the problem is with the over-saturation of the development world with people who do not care about doing things correctly or safely but instead quickly and cost-effectively.
This is not unique to io_uring, however. Let's not throw the baby out with the bathwater.
> And all the fanciest programming language type safety in the world won't save you.
I agree whole-heartedly.
> Expect several years of easy remote exploits down the road...
I would rather be interested to see which sidechannels were attacked in order to take advantage of io_uring. Those vulns are going to lay with the framework implementors and the users of frameworks, less with io_uring. But I understand the concern.
Well, the security credentials of a file descriptor are established at ```open()``` time. Is this really so different?
Running through the list of io_uring opcodes, only two of them work on ```char*``` paths: IORING_OP_OPENAT and IORING_OP_OPENAT2, which were added to io_uring after it was introduced. All the rest operate solely upon already-opened file descriptors, and POSIX doesn't do any permission checks for operations on already-open descriptors anyways.
It sounds like the issue you mention was an oversight when IORING_OP_OPENAT(2) were added. The easy, and retroactively safe, fix is to forbid these opcodes on submission queues by default, unless the submission queue was opened with a special flag whose name includes a scary warning -- something like IOURING_I_WILL_NOT_SETUID_WITHOUT_CLOSING_THIS_RING_FIRST.
https://unixism.net/loti/ref-iouring/io_uring_enter.html