> Seems like less of a rust issue and more of a bug(s) in io_uring?

I'm working with io_uring currently and have to disagree hard on that one; io_uring definitely has issues, but the one here is that it's being used incorrectly, not something wrong with io_uring itself.

The io_uring issues overall also disaggregate in mostly 2 overall categories:

- lack of visibility into io_uring operations since they are no longer syscalls. This is an issue of adding e.g. seccomp and ptrace equivalents into io_uring. It's not something I'd even call a vulnerability, more of a missing feature.

- implementation correctness and concurrency issues due to its asynchronicity. It's just hard to do this correctly and bugs are being found and fixed. Some are security vulnerabilities. I'd call this a question of time for it to get stable and ready but I have no reason to believe this won't happen.

Strongly disagree. At the level of io_uring (syscalls/syscall orchestration), it is expected that available tools are prone to mis-use, and that libraries/higher layers will provide abstractions around them to mitigate that risk.

This isn't like the Rust-vs-C argument, where the claim is that you should prefer the option of two equivalently-capable solutions in a space that doesn't allow mis-use.

This is more like assembly language, or the fact that memory inside kernel rings is flat and vulnerable: those are low-level tools to facilitate low-level goals with a high risk of mis-use, and the appropriate mitigation for that risk is to build higher-level tools that intercept/prevent that mis-use.

Full ACK.

To bring it back to the FD leak in the original post: the kernel won't stop you from forgetting to call close() either, io_uring or no.

> Being ALLOWED to be used badly

I don't see how you stop devs from using a system call or similar incorrectly. In this case the result is an FD leak, which is no more than a DoS, and easy to chase and fix [unless the library in question is designed in such a way that the problem is unfixable, in which case abandon that library].

Those are separate issues. The blog post is about using it properly in userspace, google's concerns are about kernel security bugs.

Reminds me of that panic over Linux namespaces because they kept surfacing vulnerabilities in existing software that used to run as root.

It's such a shame. The io_uring interface is one of the coolest features of the kernel. It's essentially an asynchronous system call interface. A sane asynchronous I/O interface that finally did it right after many tries. Sucks to see it just get blocked everywhere because of vulnerabilities. I hope whatever problems it has get fixed because I want to write software that uses io_uring and I absolutely want to run said software on my phone with Termux.

That is all well and true, and the vulnerabilities are getting fixed, but that is off-topic to the posted article.

The article is more about the Rust io_uring async implementation breaking assumption that Rust's async makes, in that a Future can only get modified when it's poll()-ed.

I'm guessing that assumption came from an expectation that all async runtimes live in userland, and this newfangled kernel-backed runtime does things on its own inside the kernel, thus breaking the original assumption.

The problem has been known from the beginning, because async I/O on Windows has the same issues as io_uring.

Rust went with poll-based API and synchronous cancellation design anyway, because that fits ownership and borrowing.

Making async cancellation work safely even in presence of memory leaks (destructors don't always run) and panics remains an unsolved design problem.

I mean, it’s only a problem if your design is based on the Future having exclusive ownership of its read buffer, but io\_uring assumes a kind of shared ownership. The “obvious” solution is to encode that ownership model in the design, which implies some kind of cancellation mechanism. C and C++ programs have to do that too.