Rust Bindings Are Being Worked On For Linux CPUFreq Drivers

[Avamander]

After spending an entire weekend debugging a few OOB accesses and null-pointer dereferences in a kernel driver, I for one, can't wait for more Rust in the kernel. It's not even remotely funny how difficult doing these things correctly in C is compared to Rust.

[rmoog]

Has anyone actually scanned the Linux kernel with SonarQube or any static analysis tools? Klocwork even?

[darkonix]

rmoog Mmm... It's not like Rust avoids errors:

Static Analyzer Rudra Found over 200 Memory Safety Issues in Rust Crates

https://www.infoq.com/news/2021/11/rudra-rust-safety/

CVEs (Common Vulnerabilities and Exposures) in Rust programs:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust/

If a sound static analyzer were deployed, we could make C code with zero memory safety issues and do it without the hack of compiler added runtime checks that Rust uses to claim memory safety. The aviation and nuclear power industries have been doing this for years. It is a shame that no one is willing to follow their lead and the wider community instead pursues new languages when what it actually needs is better tooling, which at present only exists for C (and C++ if you don't insist on having a formally verified compiler). Those new languages do not have such tooling and need it to reach parity with what is possible with C when using tools like sound static analyzers and formally verified compilers. :/
-- ryao on https://www.phoronix.com/forums/foru...35#post1385835

Nobody says that there can not be memory leak or a vulnerability in Rust. What it is really about is eliminating some very common classes of memory errors completely that C can not do anything about, and that is built-in, doesn't requires anything extra. I find it very unlikely that even with those static analyzers C could be even in parity in that regard. And other than that Rust being a more recent language brings some modern programming techniques like the error handling (catches a lot of errors that are left as an exercise to C programmers), integrated build system and package management (no C standard) and other things. Nobody is forced to like it though.

The analysis of crates you shared is from 2021. Anything more recent?

[rmoog]

Anything more recent?

Don't give feedback to rust users, they'll just use it to double down

[Avamander]

I find it very unlikely that even with those static analyzers C could be even in parity in that regard.

They can't, there just isn't enough info in the source itself. Anyone who has used ASAN or Valgrind knows how noisy it gets because the tools have to "guess".

[darkonix]

Don't give feedback to rust users, they'll just use it to double down

I think it fair to ask for more recent information to verify if the situation has improved in since 2021 or remains the same. I didn't negate the information. I don't understand your comment.

[hamishmb]

At the risk of feeding the troll, what is MISRA, I've never heard of it before?

[cj.wijtmans]

Bad coders fleeing to rust will manage to create safety bugs even in rust. Impressive.

[ssokolow]

At the risk of feeding the troll, what is MISRA, I've never heard of it before?

Motor Industry Software Reliability Association. They publish guidelines like MISRA C and there are static analyzers to check that programmers coding automotive firmware stick to the restricted subset spec'd by the guidelines.

[ssokolow]

Bad coders fleeing to rust will manage to create safety bugs even in rust. Impressive.

But Rust was designed to give the good coders the tools they need to push back: A compiler designed to incorporate the last few decades of learning about what compile-time enforceable invariants need, a versatile type system to teach it new invariants, and a safe/unsafe split with a #![forbid(unsafe_code)] annotation that allows you to prevent contributors to modules which shouldn't need to step outside the safety-enforcing abstractions from doing so.