KMSAN Patches For The Linux Kernel Updated For Catching Uninitialized Memory Problems

[phoronix]

Phoronix: KMSAN Patches For The Linux Kernel Updated For Catching Uninitialized Memory Problems

One of the Linux patch series that has been in the works for years in conjunction with Clang compiler side changes and already being responsible for exposing hundreds of kernel bugs is the KernelMemorySanitizer (KMSAN). Sent out today was the latest patch series working on the kernel infrastructure for catching uninitialized memory issues...

https://www.phoronix.com/scan.php?page=news_item&px=KernelMemorySanitizer-2022

[andrebrait]

inb4 "they should use Rust" comments.

Though they're right. It's the only systems programming language capable of making these issues really go away.

[EvilHowl]

inb4 "they should use Rust" comments.

Though they're right. It's the only systems programming language capable of making these issues really go away.

I really wish you were kidding.

[Jannik2099]

inb4 "they should use Rust" comments.

Though they're right. It's the only systems programming language capable of making these issues really go away.

Not quite the only one - in C++ you usually won't have uninitialized classes / structs either as it has the same RAII semantics as Rust, though unlike Rust it still gives you a footgun if you want to (not that that'd be helpful here)

But no, it'd be foolish to say that the problem of uninitialized memory has only been solved with Rust - practically every language BUT C solved it.

[andrebrait]

Not quite the only one - in C++ you usually won't have uninitialized classes / structs either as it has the same RAII semantics as Rust, though unlike Rust it still gives you a footgun if you want to (not that that'd be helpful here)

But no, it'd be foolish to say that the problem of uninitialized memory has only been solved with Rust - practically every language BUT C solved it.

When I said "issues" I ended up not being specific, but unitialized memory is only one issue in the class of problems regarding memory management. Rust is, AFAIK, the only language that has managed to solve almost all issues in that class.

So yeah, using C++ solves some, but it won't solve all, at least not in a way that's usable in the kernel. I don't think they'd want to use smart pointers, or any C++ at all to begin with.

[arQon]

> Such bugs keep getting introduced into the kernel despite new compiler warnings and other analyses

That's the interesting part.

Something's fishy here, because we had *compilers* that would bitch about uninitialized variables literally decades ago, let alone secondary tools like Coverity etc, and under -Werror that gets you a failed build. So either something has gone very backwards with compilers, or somebody is disabling warnings en masse in their code and none of the reviewers have any problem with that.

[karolherbst]

> Such bugs keep getting introduced into the kernel despite new compiler warnings and other analyses

That's the interesting part.

Something's fishy here, because we had *compilers* that would bitch about uninitialized variables literally decades ago, let alone secondary tools like Coverity etc, and under -Werror that gets you a failed build. So either something has gone very backwards with compilers, or somebody is disabling warnings en masse in their code and none of the reviewers have any problem with that.

I don't think any of that works if you start passing pointers to stack memory around, otherwise most compilers would spam millions of warnings at every C project, because you never know if the function reads from your pointer or writes to it (e.g. you use a function to initialize your struct on the function stack).

[arQon]

I don't think any of that works if you start passing pointers to stack memory around

You're probably right about "X* p; foo(&p); *p=42;" cases (where foo() has a path that doesn't populate p) being overlooked by the compiler, but it certainly gets caught by Coverity etc.