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

Flummox the interviewer

[Snotnose]

Some 20 years ago I was consulting for a company that needed $BigCompay approval to release software. While at $BigCompany I ran across an old boss, who flat out said "interview with us, you're in". I did.

One guy asked the standard string reversal question, in C. I put a pointer at each end of the string and walked them together. The guy was completely flummoxed, it was like he'd never encountered an answer he hadn't thought of. This was like the second question he asked me, we spent the rest of the interview me explaining my solution, he never understood it.

Guy turned out to be my sorta boss (matrix management means the guy you report to has no say in your performance review). He was a good guy, one of the early employees of the company, but as time went on I realized he did not understand C pointer arithmetic.

Mind you, this guy was smarter than me, and more driven. But he had never done assembly programming, hence he never really understood C pointers.

Me? Started with Z-80 assembly, moved to 8080, 8086, then 80386, which is when I learned C. Took to C pointers like a duck to water.

FWIW, the company I was consulting for never paid me for my last month (2 bi-weekly paychecks). Lots of phone calls, meetings, and fights. Huge reason I quit consulting and went back to working for companies.

The problem is this

[DrXym]

Approximately 50% of all CVEs related to the kernel are DIRECTLY caused by the language the kernel is written in - buffer overflows, double frees, null pointers etc. If arguably some of the most seasoned, experienced programmers of C can make these mistakes what does it say of code written elsewhere? And that's with the benefit of code reviews, coverage tools, and independent scrutiny.

So all this talk of C/C++ being big boy's language and only a manly man should program it and it's your own fault if you write bugs is just so much bollocks. C and C++ are old languages and they have flaws that can be mitigated but not eliminated. That's Rust is so worthy of consideration - it eliminates that 50% of bugs by design and compiles with performance equivalent to C. Rust also makes it easier to write safe concurrent code, so performance can even exceed C/C++.

That said, I understand why the Linux kernel is kind of stuck where it is, but for new projects, or existing projects undergoing major rewrites, I would at least evaluate Rust first before defaulting to a C language.

Re:Don't be lazy programmers

[phantomfive]

I wonder if C or another language could not rely on API's or API-like expansion macros. A given shop would select the API's that fit its trade-off profile. If you wanted to skip pre-initialization for speed, you'd use the skipping version of an initializer API. And on the flip side, don't include the non-init API in the shop stack if you don't want accidental naked bits.

I worked for a company that did something similar......they wrote their own version of malloc() etc to avoid memory leaks. About a year after I started working there, the Javascript coders had to spend several weeks fixing all the memory leaks in their code. The C coders had none. Ignoring the problem doesn't make it go away.

Re:C is beautiful

[Anonymous Coward]

But there is something to the beauty and the immediacy of having a computer not trying to think for you.

There’s something beautiful and immediate about driving without power steering, ABS, traction control, etc. too, but at the end of the day we need to admit that’s best left on a track, for sport and entertainment, and not every day use.