Safer Linux Kernel Modules Using the D Programming Language

[Siarhei Siamashka]

On Wednesday, 11 January 2023 at 09:44:27 UTC, Walter Bright 
wrote:
>> Bounds checking in the Linux kernel is done by 
>> https://docs.kernel.org/dev-tools/kfence.html or
>
> Being sampling based, this is not good enough.

I disagree. KFENCE is actually a perfect fit for what is needed 
for the Linux kernel. LTS kernel releases are maintained for many 
years and keep getting bugfixes. They also have a large userbase. 
It means that after a year or so, most of the bugs of this kind 
can be caught and fixed. All of this with near zero performance 
overhead.

The reactive nature of this approach and also reliance on the 
"safety in numbers" idea works best for slowly evolving popular 
software. But I agree that it won't be good enough for a rapidly 
evolving unpopular application. Or when the cost of encountering 
a bug on the end user system is way too high.

> Please don't misunderstand me, these tools are good. But they 
> have really nothing to do with the C language specification

They have everything to do with the C language specification, 
because they improve memory safety specifically for C language.

> (which is completely unhelpful in resolving this issue), have 
> too high overhead to be useful in a shipped product,

They are extremely effective and widely used in practice for 
developing any modern software in C language.

> and have not stopped C from having buffer overflows being the 
> #1 bug in shipped software.

They surely prevented and/or allowed to debug and fix a large 
number of buffer overflows. Is your claim about the #1 bug 
actually backed by anything? The statistics from Chromium seems 
to disagree and there are also a lot of problems on the list even 
not related to memory safety: 
https://forum.dlang.org/post/mailman.2828.1670270281.31357.digitalmars-d@puremagic.com

> I stand by the idea that C's semantics make it impossible. 
> These tools are all things layered on top of C, and they 
> certainly help, and I would use them if I was developing in C, 
> but they simply do not solve the problem.

They only partially solve the problem and they surely have 
tradeoffs. Just like D also only partially solves the memory 
safety problem and has its own tradeoffs. A honest comparison 
needs to take this into account and then you will probably see 
why D does not look like a perfect solution. And why Rust is 
eating D's lunch.