KernelMemorySanitizer v4 Published While Already Having Found 300+ Kernel Bugs

[phoronix]

Phoronix: KernelMemorySanitizer v4 Published While Already Having Found 300+ Kernel Bugs

Being worked on the past several years by Google engineers and others has been the KernelMemorySanitizer (KMSAN) that has already found more than 300 kernel bugs even prior to being mainlined. Sent out prior to the US holiday weekend as the fourth iteration of these patches, building off the "request for comments" sent out in 2020...

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

[microcode]

A lovely way to start Independence day.

[waxhead]

It would be interesting to see how much of a performance impact it would be for the kernel to zero out ALL memory at boot. Then when an application calls free() - pass it onto a "zero memory" worker thread before it is allowed to be allocated again...

Sure, it will slow things down quite a bit , but if all memory being allocated is already zeroed by a free() , how bad would it be really?

[microcode]

That would be very very slow, like... twice as much time spent in the kernel slow.

[mb_q]

That would be very very slow, like... twice as much time spent in the kernel slow.

Not according to what is in the linked beam:

Performance costs [for stack]
-----------------
* 0xAA initialization (used in the kernel now)
- ~0% for netperf and parallel Linux build
- 1.5% for hackbench
- 0-4% for Android hwuimacro benchmarks
- 7% for af_inet_loopback
* 0x00 initialization
- ~0% slowdown for hackbench, netperf, Linux build
- 0-3% for Android benchmarks
- 4% for af_inet_loopback
On ARM64 some benchmarks actually became faster!

[for heap]
* init_on_alloc=1
- ~0% for parallel Linux build (QEMU/x86)
- Android hwuimacro: 0.5-1.5% (ARM64)
- hackbench: 2.9% (ARM64), ~7% (QEMU/x86)
* init_on_free=1
- Android hwuimacro: 0.5-3% (ARM64)
- hackbench: ~7% (QEMU/x86)
- 8% for parallel Linux build

They actually propose to make explicit initialisation a part of C -- so that the compiler could initialise by default and then optimise the initialisation out if it is done by the programmer; a strong Rust vibe here.

[bug77]

Not looking to start a debate, but I have to point out rustc does all this by default.

[kiffmet]

I'm currently using GCC_PLUGIN_STRUCTLEAK_BYREF_ALL, GCC_PLUGIN_STACKLEAK and INIT_ON_ALLOC_DEFAULT_ON to prevent/mitigate most bugs/exploits involving uninitialized memory. I'm using my system for multimedia, gaming and compiling lots of code - so far I can't complain about performance and frametimes, compared to Windows 10 (5900X).

[ayumu]

As a reminder, many more bugs sit undetected. When the kernel is millions of LoCs, you're gonna have bugs.

The only workable solution is to switch to a microkernel multiserver architecture, such as Genode on seL4.

Linux is bankrupt, architecture-wise.

[paulpach]

As a reminder, many more bugs sit undetected. When the kernel is millions of LoCs, you're gonna have bugs.

The only workable solution is to switch to a microkernel multiserver architecture, such as Genode on seL4.

Linux is bankrupt, architecture-wise.

well, Genode on seL4 is also millions of lines of code and will also have bugs.
But I get your point, those bugs would not be running in kernel mode, so the damage they can do is much more limited.

Here is the problem: Suppose I tell you:
"Here is an operating system that has 1/10 the security problems and never crashes, but is 2-3x slower."
Would you use it on your desktop/laptop? Most people would say no. The reality is that we value performance a lot more than we value security and stability.

If we are to ever switch to microkernels, we have to solve the performance problems, otherwise, they are dead on arrival no matter how stable and secure they are.

[jbranso]

Here is the problem: Suppose I tell you:
"Here is an operating system that has 1/10 the security problems and never crashes, but is 2-3x slower."
Would you use it on your desktop/laptop? Most people would say no. The reality is that we value performance a lot more than we value security and stability.

If we are to ever switch to microkernels, we have to solve the performance problems, otherwise, they are dead on arrival no matter how stable and secure they are.

Thanks for being civil. There's been quite a few people sh*t posting here. Thanks for not doing that here.

Also have ya'll heard about Drew Devault's now microkernel OS?

https://drewdevault.com/2022/06/13/helios.html

He just ported Doom to it:

https://drewdevault.com/2022/07/01/Porting-DOOM-to-Helios.html