Post #2171011

2024-09-13 12:19 UTC

This &quot;untrusted data&quot; patch series from Benno Lossin is the result of conversations at last weekend&#39;s Rust Linux kernel conference in Copenhagen: https://lore.kernel.org/all/20240913112643.542914-1-benno.lossin@proton.me/ It&#39;s not a &quot;silver bullet&quot; for why we should be using rust in the Linux kernel, but it is a &quot;big giant sledgehammer&quot; to help squash and prevent from happening MANY common types of kernel vulnerabilities and bugs (remember, &quot;all input is evil!&quot; and this change forces you to always be aware of that, which is something that C in the kernel does not.) I had always felt that Rust was the future for what we need to do in Linux, but now I&#39;m sure, because if we can do stuff like this, with no overhead involved (it&#39;s all checked at build time), then we would be foolish not to give it a real try. And yes, I&#39;ve asked for this for years from the C developers, and maybe we can also do it there, but it&#39;s not obvious how and no one has come up with a way to do so. Maybe now they will have some more incentive :)

Replies (2)

@gregkh@social.kernel.org 2024-09-14 06:38

In the same topic of "use frameworks to make bugs very hard to create", Alice Ryhl's patches for using a "range" api to access data from userspace: https://lore.kernel.org/r/20240913210031.20802-1-aliceryhl@google.com along with examples of how recent binder bugs were affected by this issue in C, and also were present in the Rust implementation, along with a proposal for how to prevent that are another good example of how the language can help us in kernel land by creating apis to help us do the right thing.

Open ##2186850
@hipsterelectron@circumstances.run 2024-09-14 08:20

@gregkh@social.kernel.org The API introduced in this series is not a silver bullet, users are still able to access the untrusted value (otherwise how would they be able to validate it?). But it provides additional guardrails to remind users that they ought to validate the value before using it. As already stated, they can access the value directly, but to do that, they need to explicitly call one of the untrusted_* functions signaling to reviewers that they are reading untrusted data without validation. this does not seem to indicate that anything is being checked at build time? is there a part of the patch that demonstrates the zero-overhead build-time checking you describe? or is your point that the rust for linux people are receptive to these concerns and other kernel devs aren't? i'm confused by "this change forces you to always be aware of that, which is something that C in the kernel does not" when the part i quoted very explicitly says it is not a silver bullet and just provides additional guardrails (which is obviously useful, i'm not contesting that)

Open ##2186851