2 ms·

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

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

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