3 ms·

> While io_uring brings performance benefits, and promptly reacts to security > issues with comprehensive security fixes (like backporting the 5.15 version

> While io_uring brings performance benefits, and promptly reacts to security > issues with comprehensive security fixes (like backporting the 5.15 version > to the 5.10 stable tree), it is a fairly new part of the kernel. As such, > io_uring continues to be actively developed, but it is still affected by > severe vulnerabilities and also provides strong exploitation primitives. For > these reasons, we currently consider it safe only for use by trusted > components. As often in the kernel (and probably everywhere): there are people caring for performance and there are people caring for security, and a lot of the time there's not that much overlap. Ensuring that io_uring is covered by the Linux Security Modules (LSM) framework, that provides hooks for things like AppArmor or SELinux (and a variety of others, some even can even get stacked), was only done after it was already quite popular. So FWICT, even if io_uring is existing since a while, 1) the security experts vetting it are looking only closer since relatively recently and 2) it's architecture is quite different from other kernel user space interfaces, which certainly needs some adaptions on applying the established security mechanisms of the kernel, especially as the project still wants to stay high performance. IMO, this doesn't mean io_uring is inherently unsafe, or has no use, but that one certainly needs to evaluate if great async submission model is worth the potential security implications. E.g., in an isolate environment, where no untrusted third-party apps or people have access, it can be fine, while especially in environments that Google runs it isn't worth the trouble for now. But, I think that the features which io_uring brings are too nice to have for quite some (I/O or syscall heavy) workloads even in those environments, so there will be an incentive it to the integration into the existing Linux security stack and mechanisms, and evolve the latter to be also a good fit for this rather different interface.

udunadan 3y ago
Yes, it is no different than OPSEC with heavy procedures in place which take the actor's mobility at the sake of security. A universal security property.
rfoo 3y ago
> integration into the existing Linux security stack It's less about integration into the security stack. It's just that the implementation of io_uring is hard to get right, and at 2023 there seems to be an endless stream of race condition bugs. Quite like user namespaces ten years ago. It doesn't matter how good your security design is. Hackers just find a memory corruption bug and get around everything. To be fair it isn't endless, finding an io_uring bug which can be exploited to cause memory corruption and ultimately kernel code execution in 5.15 tree is measurably harder now. But io_uring moves very fast and it's an entirely different story for mainline kernels.
- tlamponi 3y ago
  > It's less about integration into the security stack. Yes, that's why I wrote: >> it's architecture is quite different from other kernel user space interfaces, which certainly needs some adaptions on applying the established security mechanisms of the kernel But user namespaces are actually a very good examples, they also broke with a lot of things that were often used as axiom, so there really are some parallels to io_uring from that POV. > Hackers just find a memory corruption bug and get around everything. If the Rust experiment pans out well, it could make a lot of such bugs straight out impossible, at least if devs aren't bending backwards to lower the risk to roughly the same as C now has in the best case. At least at $work this pans out quite nicely.
  - cmrdporcupine 3y ago
    While I like Rust and get paid to work in it, and am happy it's now possible to work in the kernel in it, I am skeptical about the promise of Rust to solve issues like this, honestly; at least the for short term... Because I think once you get down to the kind of code being written here it's going to be chock full of unsafe {} and UnsafeCell and various snakey error-prone tricks to make the borrow checker work in the context of the entirely different world that is the kernel, closer to the metal. And so realistically most of the same issues that impact C code will happen here. I haven't looked at the io_uring security issues in general but I've used io_uring (from Rust) and I can see how it could go wrong. And I can see that if one was writing a facility like this in Rust it could end up subject to many of the same issues, because in the end io_uring is holding references to user instructions and executing them in a pretty privileged context. Many things could go wrong here: how one manages ownership, what the boundaries between this thing and the rest of the kernel look like, etc. There's no magic bullet that Rust provides there, other than perhaps an expectation of a certain kind of borrowing discipline? Hopefully Google shutting this down in their GKE environment doesn't spread beyond into AWS and Azure hosted instances, etc. because I think there's plenty of people who will be impacted quite negatively. io_uring has incredible promise, and the kinds of companies that it will hurt are the fairly innovative ones pushing the envelope for database or server tech generally (including a former employer of mine!).

udunadan 3y ago

Yes, it is no different than OPSEC with heavy procedures in place which take the actor's mobility at the sake of security. A universal security property.

rfoo 3y ago

> integration into the existing Linux security stack It's less about integration into the security stack. It's just that the implementation of io_uring is hard to get right, and at 2023 there seems to be an endless stream of race condition bugs. Quite like user namespaces ten years ago. It doesn't matter how good your security design is. Hackers just find a memory corruption bug and get around everything. To be fair it isn't endless, finding an io_uring bug which can be exploited to cause memory corruption and ultimately kernel code execution in 5.15 tree is measurably harder now. But io_uring moves very fast and it's an entirely different story for mainline kernels.

tlamponi 3y ago
> It's less about integration into the security stack. Yes, that's why I wrote: >> it's architecture is quite different from other kernel user space interfaces, which certainly needs some adaptions on applying the established security mechanisms of the kernel But user namespaces are actually a very good examples, they also broke with a lot of things that were often used as axiom, so there really are some parallels to io_uring from that POV. > Hackers just find a memory corruption bug and get around everything. If the Rust experiment pans out well, it could make a lot of such bugs straight out impossible, at least if devs aren't bending backwards to lower the risk to roughly the same as C now has in the best case. At least at $work this pans out quite nicely.
- cmrdporcupine 3y ago
  While I like Rust and get paid to work in it, and am happy it's now possible to work in the kernel in it, I am skeptical about the promise of Rust to solve issues like this, honestly; at least the for short term... Because I think once you get down to the kind of code being written here it's going to be chock full of unsafe {} and UnsafeCell and various snakey error-prone tricks to make the borrow checker work in the context of the entirely different world that is the kernel, closer to the metal. And so realistically most of the same issues that impact C code will happen here. I haven't looked at the io_uring security issues in general but I've used io_uring (from Rust) and I can see how it could go wrong. And I can see that if one was writing a facility like this in Rust it could end up subject to many of the same issues, because in the end io_uring is holding references to user instructions and executing them in a pretty privileged context. Many things could go wrong here: how one manages ownership, what the boundaries between this thing and the rest of the kernel look like, etc. There's no magic bullet that Rust provides there, other than perhaps an expectation of a certain kind of borrowing discipline? Hopefully Google shutting this down in their GKE environment doesn't spread beyond into AWS and Azure hosted instances, etc. because I think there's plenty of people who will be impacted quite negatively. io_uring has incredible promise, and the kinds of companies that it will hurt are the fairly innovative ones pushing the envelope for database or server tech generally (including a former employer of mine!).