Put an io_uring on it – Exploiting the Linux Kernel (2022) | Hacker News Reader

Put an io_uring on it – Exploiting the Linux Kernel (2022)

chompie.rip

176 pointsfragmede23 comments

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

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.

Recent and related:

Learnings from kCTF VRP's 42 Linux kernel exploits submissions - https://news.ycombinator.com/item?id=36350693 - June 2023 (87 comments)

Past discussion of current article:

Put an io_uring on it: Exploiting the Linux kernel - https://news.ycombinator.com/item?id=30605356 - March 2022 (22 comments)

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?

0: http://web.archive.org/web/20221130215710/https://www.grapls...

1: https://news.ycombinator.com/item?id=30605356

Chompie is fantastic at making things readable.

yeah, chompie rules

Previous discussion on hnnews when this was originally submitted as a Graph Security piece: https://news.ycombinator.com/item?id=30605356

This is now mirrored since Grapl shut down (RIP)

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

Discussed here: https://news.ycombinator.com/item?id=36350693

Thanks to you both! I've macroexpanded these links at the toplevel: https://news.ycombinator.com/item?id=36361124

> If the operation can be done without blocking, it will be completed synchronously in the context of the calling thread.

My careers been in mobile, I thought “blocking” and “synchronous” were synonymous.

Does blocking in this context mean “needs to make a system call?”

I think it means "entering a state where the thread has nothing to do but wait." An "add" instruction is synchronous but I wouldn't say it "blocks".

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

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

"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 :)

Does FreeBSD have anything similar to io_uring?

My understanding is its incorrect to compare to kqueue.

> Does FreeBSD have anything similar to io_uring?

No. (Not for security reasons, but for lack of an army of motivated and talented developers like Jens Axboe et al.)

> My understanding is its incorrect to compare to kqueue.

Right. kqueue is more like an extended version of epoll.

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

kqueue is most comparable to epoll.

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?

(Thank you & the team for all you do)

Not that I'm aware of. The sendfile path is our hottest path, and that's already improved immensely by async sendfile.

(2022)

Added. Thanks!

Reply on news.ycombinator.com