[HN Gopher] Put an io_uring on it - Exploiting the Linux Kernel ...
___________________________________________________________________
Put an io_uring on it - Exploiting the Linux Kernel (2022)
Author : fragmede
Score : 161 points
Date : 2023-06-16 09:35 UTC (13 hours ago)
(HTM) web link (chompie.rip)
(TXT) w3m dump (chompie.rip)
| twunde wrote:
| 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)
| TechieKid wrote:
| 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-...
| loeg wrote:
| Discussed here: https://news.ycombinator.com/item?id=36350693
| dang wrote:
| Thanks to you both! I've macroexpanded these links at the
| toplevel: https://news.ycombinator.com/item?id=36361124
| [deleted]
| refulgentis wrote:
| > 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?"
| Arnavion wrote:
| "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.
| skulk wrote:
| 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".
| Arnavion wrote:
| >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.
| [deleted]
| ithkuil wrote:
| "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.
| alberth wrote:
| Does FreeBSD have anything similar to io_uring?
|
| My understanding is its incorrect to compare to kqueue.
| loeg wrote:
| > 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.
| hedora wrote:
| 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).
| drewg123 wrote:
| 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.
| alberth wrote:
| 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)
| dang wrote:
| 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)
| a1369209993 wrote:
| 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
| Sarkie wrote:
| Chompie is fantastic at making things readable.
| gaze wrote:
| yeah, chompie rules
| hedora wrote:
| 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.
| shp0ngle wrote:
| (2022)
| dang wrote:
| Added. Thanks!
___________________________________________________________________
(page generated 2023-06-16 23:02 UTC)