Safer Linux Kernel Modules Using the D Programming Language

[Walter Bright]

On 1/10/2023 10:49 PM, Siarhei Siamashka wrote:
> It's impractical to have this in the ISO standard, but surely not impossible. 
> Various C compilers from different vendors implement bounds checking. See:
> 
>    * https://bellard.org/tcc/tcc-doc.html#Bounds

This works by constructing a data structure of all the allocated memory, and 
then comparing a pointer dereference to see if it's pointing to valid data. It 
sounds like what valgrind does. It's very slow, and wouldn't be used in a 
shipped executable, like you wouldn't ship valgrind. It's vulnerable to memory 
corruption when your app gets tested with inputs that were never tested when 
this checking was turned on.


>    * https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html

Adds a bunch of runtime checks you wouldn't want to ship an executable with them 
turned on.

>    * https://clang.llvm.org/docs/AddressSanitizer.html

Same problem. 2x slowdown, won't use it in shipped executable.

>    * 
> https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-use-native-run-time-checks?view=vs-2022

Not really clear what this does.


> So your statement that "C has no mechanism to prevent them" just ignores reality 
> and the existing C compilers. If you are comparing the lowest common denominator 
> ISO C spec with the vendor specific DigitalMars D implementation, then this is 
> not a honest apples-to-apples comparison.

They all seem to have the same problem - they are only useful when the program 
is under test. When the program is shipped, they're not there.

> The Linux kernel is using GNU C compiler and recently switched from `-std=gnu89` 
> to `-std=gnu11`.
> 
> 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.


> https://docs.kernel.org/dev-tools/kasan.html

Another test-only tool.

Please don't misunderstand me, these tools are good. But they have really 
nothing to do with the C language specification (which is completely unhelpful 
in resolving this issue), have too high overhead to be useful in a shipped 
product, and have not stopped C from having buffer overflows being the #1 bug in 
shipped software.

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.