How Linux's Kernel Developers 'Make C Less Dangerous' (hpe.com)

Hewlett-Packard's Enterprise blog summarizes a talk by Linux kernel developer Kees Cook at the North America edition of the 2018 Linux Security Summit. Its title? "Making C Less Dangerous." "C is a fancy assembler. It's almost machine code," said Cook, speaking to an audience of several hundred peers, who understood and appreciated the application speed resulting from C... Over time, Cook and the people he worked with discovered numerous native C problems. To deal with these weaknesses, the Kernel Self Protection Project has worked slowly and steadily on protecting the Linux kernel from attack. In the process, it has worked to remove troublesome code from Linux....

With its operational baggage and weak standard libraries, C contains a great deal of undefined behavior. Cook cited -- and agreed with -- Raph Levien's blog post "With Undefined Behavior, Anything Is Possible." Cook gave concrete examples. "What are the contents of 'uninitialized' variables? Whatever was in memory from before! Void pointers have no type, yet we can call typed functions through them? Sure! Assembly doesn't care: Everything can be an address to call! Why does memcpy() have no 'max destination length' argument? Just do what I say; memory areas are all the same!" Some of these idiosyncracies are relatively easy to deal with. Cook commented, "Linus [Torvalds] likes the idea of always initializing local variables. So, you should 'just do it....'"

The long-term solution? More security-savvy open source developers... While at times, the idea of coming up with a Linux C dialect has been attractive, that's not going to happen. The real issue behind the problem of dangerous code is "people don't want to do the work to clean up code -- not just bad code, but C itself," he said. As with all open source projects, "we need more dedicated developers, reviewers, testers, and backporters."
LWN.net has its own run-down of Cook's talk, as well as a link to a PDF file of his slides.

"Sound good," posted one of their commenters, "though ultimately I'd like kernel devs to adopt Rust as their main Linux kernel development language. Beats the crap out of C and C++ combined."

Comments

Re:Don't be lazy programmers

[gweihir]

> it's not 'child proofed'

Programming languages, in general, need to be human proofed. We have a ton of empirical data to support this for decades.

No, you do not. Sure, when you let incompetents write advanced things, it will lead to them making harder to find bugs. But that is something else entirely. Now go back to play with VB or JavaScript.

Re:Here's why...Not invented here syndrome

[willy_me]

Rust is for morons with delusions that do not have what it takes but think they can write advanced code anyways.

Oh please... Rust is for people that want to be more productive with their time at the expense of some additional system resources. For the majority of software projects it is a good deal.

Operating Systems are a bit different. Every bit of performance and every bit of memory matter. The OS is being run in enough places, on different hardware, that even a small difference is performance can be noticeable. The code is important enough such that the additional time and effort required to ensure the C code is done correctly is time well spent. For most other applications, it would be wasted effort.

Now let us not forget that Rust is also dependent on LLVM so it has limited hardware support. I suppose such support could be added but it is far too soon to be suggesting that an OS, which is supposed to be able to run on almost anything, should be using it.

Re:Here's why...Not invented here syndrome

[gweihir]

Ah, the old "you don't know it until you try it" fallacy so dear to fanatics of all kinds.