Tokio-Uring Design Proposal
github.com
github.com
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.
/* 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)
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.