So, going through the 2023 CVE's for io_uring, this is the only one that impacts the 6.x kernel line. The rest were targeting 5.10 (except one for 5.19).
That tells me that io_uring stabilized a lot during 2021.
Google yanking support for it seems like a bad decision. Instead, they should upgrade their 3-year-old kernels, which certainly contain other fixed-but-not-backported security vulnerabilites.
Submitted URL doesn't load because of Javascript. Content appears to be available at [0] (previously (non-archive.org) submitted as [1]). Is that actually the same article?
Also relevant news that Google has disabled io_uring for apps on Android and disabled it entirely on Chrome OS and production Google servers since 60% of the exploits (~$1M worth) submitted to the Google Vulnerability Rewards Program have been for io_uring: https://security.googleblog.com/2023/06/learnings-from-kctf-...
"Blocking (on IO)" in OS jargon means that the thread can yield the CPU to other threads because it's otherwise waiting for some external event (e.g. some IO operation to complete).
When the IO operation is ready the thread is then marked to be awakened and the scheduler will context switch back to it whenever it sees fit (given other considerations like thread priority, etc).
From the POV of the thread that blocks nothing really happens while it's waiting. Once it awakens it has the result of the operation (or an error) and it can observe that more time has passed by inspecting the timer. For all intents and purposes the operation was "synchronous" from the POV of the thread.
Ty for this, Flutters been unreasonably effective for me, with an absurdly simple concurrency system, and I never quite understood why. Now I see why the simple idea of never-blocking is so effective. This comment probably sounds silly, I’m groping for words to describe my old vs. new understanding, but anyways, thanks :)
"Blocking" == "can be completed immediately" in this context, ie whether the equivalent syscall would complete immediately or if it would return EAGAIN. So if the operation can be completed immediately, it will be completed in the context of the calling thread without involving the kernel work queue. Otherwise it cannot be completed immediately, so the kernel work queue will take it and start working on it.
>I think it means "entering a state where the thread has nothing to do but wait."
No. Neither thread involved here (the userspace thread or the kernel thread) will "wait" in either scenario. The userspace thread will either work on the syscall (because it was ready to be performed immediately) or it will be released to go do something else. The kernel thread will either not be involved (because the syscall was performed by the userspace thread already) or it will start working on the syscall.
Well, it does, in that most modern hardware devices communicate over PCIe via SQ/CQ pairs, and I'm pretty sure that include virtualization device interfaces.
A lot of people are coming to the conclusion that io_uring's userspace interface is fundamentally insecure. That couldn't be farther from the truth. I've read the spec (which is only a few pages). I could implement + security validate both sides in a day or two (and have done similar in the past).
In a way, async sendfile is like iouring in that a web / file server does not have to supply a blocking thread context to wait for io -- once data arrives from the storage driver, its pushed through the TCP stack in the storage driver's ithread context. But its just that single sequence.
Drew, beyond async sendfile which you’ve already done - does Netflix have any plans to bring more general purpose iouring-like functionality to FreeBSD?
https://www.openwall.com/lists/oss-security/2023/05/08/3
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring
That tells me that io_uring stabilized a lot during 2021.
Google yanking support for it seems like a bad decision. Instead, they should upgrade their 3-year-old kernels, which certainly contain other fixed-but-not-backported security vulnerabilites.