Before anything else: yay! I'm really glad to see this RFC officially hit LKML. :) On Wed, Apr 14, 2021 at 10:20:51PM +0200, Miguel Ojeda wrote: > - On floating-point, 128-bit, etc.: the main issue is that the > `core` library is a single big blob at the moment. I have already > mentioned this to some Rust team folks. We will need a way to "cut" > some things out, for instance with the "feature flags" they already > have for other crates (or they can split `core` in to several, like > `alloc` is for similar reasons). Or we could do it on our side > somehow, but I prefer to avoid that (we cannot easily customize `core` > like we can with `alloc`, because it is tied to the compiler too > tightly). Besides just FP, 128-bit, etc, I remain concerned about just basic math operations. C has no way to describe the intent of integer overflow, so the kernel was left with the only "predictable" result: wrap around. Unfortunately, this is wrong in most cases, and we're left with entire classes of vulnerability related to such overflows. When originally learning Rust I was disappointed to see that (by default) Rust similarly ignores the overflow problem, but I'm glad to see the very intentional choices in the Rust-in-Linux design to deal with it directly. I think the default behavior should be saturate-with-WARN (this will match the ultimate goals of the UBSAN overflow support[1][2] in the C portions of the kernel). Rust code wanting wrapping/checking can expressly use those. The list of exploitable overflows is loooong, and this will remain a weakness in Rust unless we get it right from the start. What's not clear to me is if it's better to say "math with undeclared overflow expectation" will saturate" or to say "all math must declare its overflow expectation". -Kees [1] https://github.com/KSPP/linux/issues/26 [2] https://github.com/KSPP/linux/issues/27 -- Kees Cook
