3 ms·

"io_uring vulnerabilities were used in all the submissions which bypassed our mitigations."

wahern 3y ago
Everything about io_uring has screamed security nightmare from day 1--the amount of kernel attack surface it opens up, the fact it put little thought into how it interacted with process and privilege boundaries and related overarching models (see, e.g., interactions with setuid and fork/clone), increased opportunity to exploit race conditions, etc. From a pure performance standpoint it's amazing, but it's circumventing a slew of interfaces that were, at least in part, designed to restrict process privilege--more importantly than merely designed, but refined and bug-fixed over decades. The use of lockless buffers for high throughput IPC works better in microkernel designs. Linux being a monolithic kernel, io_uring is like one, big trap door for exploits.
chrismorgan 3y ago
Rephrasing the sentiments of the article: • io_uring is quite new, and currently still having some severe security problems. • Most kernel security bugs, they can mitigate effectively. But their mitigations aren’t fully effective on io_uring. • Therefore, until the security problems die down or until they can effectively mitigate io_uring security bugs, they’re disabling it, because the security concerns outweigh the performance advantages.
- johncolanduoni 3y ago
  > • Most kernel security bugs, they can sandbox effectively. But their sandboxing isn’t fully effective on io_uring. This is definitely not true in general for their platform: I don’t believe they do any shared-kernel sandboxing of untrusted code at this point and their primary sandbox gVisor (used for stuff like App Engine, Cloud Functions, and Cloud Run) just doesn’t simulate io_uring at all.
  - chrismorgan 3y ago
    “Sandboxing” was the wrong word to use; I was referring to what they call “mitigations”. Following through a few links, you can end up at https://github.com/thejh/linux/blob/slub-virtual/MITIGATION_README https://github.com/thejh/linux/blob/slub-virtual/MITIGATION_... which describes what it all actually is. I was figuring that sandboxing was probably close enough as a description, and maybe more easily understood, but that wasn’t wise. I’ve changed it to use their wording.
hedora 3y ago
The example in the article was fixed by backporting a patch from 5.15 to 5.10. 5.10 was released in October 2020. 5.15 was from November 2021. They also changed the program so they only pay out for bugs in a recent kernel. It seems more prudent to disable io_uring only on kernels that are say, over 2 years old. Alternatively, they could upgrade their known-insecure kernels. I doubt the io_uring patch is the only missing one that was produced in the last three years.
- 7e 3y ago
  That's not my read. I read that they've found a bunch of exploits in io_uring but are only willing to talk publicly about previously disclosed ones, like the one fixed by backporting to 5.10. Just because they used that as an example doesn't mean they're refusing to backport security fixes. It just means they don't want to talk about exploits they found in newer kernels, which is understandable.

Everything about io_uring has screamed security nightmare from day 1--the amount of kernel attack surface it opens up, the fact it put little thought into how it interacted with process and privilege boundaries and related overarching models (see, e.g., interactions with setuid and fork/clone), increased opportunity to exploit race conditions, etc. From a pure performance standpoint it's amazing, but it's circumventing a slew of interfaces that were, at least in part, designed to restrict process privilege--more importantly than merely designed, but refined and bug-fixed over decades. The use of lockless buffers for high throughput IPC works better in microkernel designs. Linux being a monolithic kernel, io_uring is like one, big trap door for exploits.

chrismorgan 3y ago

Rephrasing the sentiments of the article: • io_uring is quite new, and currently still having some severe security problems. • Most kernel security bugs, they can mitigate effectively. But their mitigations aren’t fully effective on io_uring. • Therefore, until the security problems die down or until they can effectively mitigate io_uring security bugs, they’re disabling it, because the security concerns outweigh the performance advantages.

johncolanduoni 3y ago
> • Most kernel security bugs, they can sandbox effectively. But their sandboxing isn’t fully effective on io_uring. This is definitely not true in general for their platform: I don’t believe they do any shared-kernel sandboxing of untrusted code at this point and their primary sandbox gVisor (used for stuff like App Engine, Cloud Functions, and Cloud Run) just doesn’t simulate io_uring at all.
- chrismorgan 3y ago
  “Sandboxing” was the wrong word to use; I was referring to what they call “mitigations”. Following through a few links, you can end up at https://github.com/thejh/linux/blob/slub-virtual/MITIGATION_README https://github.com/thejh/linux/blob/slub-virtual/MITIGATION_... which describes what it all actually is. I was figuring that sandboxing was probably close enough as a description, and maybe more easily understood, but that wasn’t wise. I’ve changed it to use their wording.

hedora 3y ago

The example in the article was fixed by backporting a patch from 5.15 to 5.10. 5.10 was released in October 2020. 5.15 was from November 2021. They also changed the program so they only pay out for bugs in a recent kernel. It seems more prudent to disable io_uring only on kernels that are say, over 2 years old. Alternatively, they could upgrade their known-insecure kernels. I doubt the io_uring patch is the only missing one that was produced in the last three years.

7e 3y ago
That's not my read. I read that they've found a bunch of exploits in io_uring but are only willing to talk publicly about previously disclosed ones, like the one fixed by backporting to 5.10. Just because they used that as an example doesn't mean they're refusing to backport security fixes. It just means they don't want to talk about exploits they found in newer kernels, which is understandable.