Kernel security: beyond bug fixing [LWN.net]

Kernel security: beyond bug fixing

Posted Oct 29, 2015 10:21 UTC (Thu) by flussence (guest, #85566)
In reply to: Kernel security: beyond bug fixing by mjthayer
Parent article: Kernel security: beyond bug fixing

After a decade on Gentoo, I've figured out all the compiler switches in the world are no substitute for simply throwing out bad software when a better tool comes along.

("Compiler switches" can be used interchangeably with "angry forum posts" in the above.)

to post comments

Kernel security: beyond bug fixing

Posted Oct 31, 2015 20:49 UTC (Sat) by marcH (subscriber, #57642) [Link] (5 responses)

> After a decade on Gentoo, I've figured out all the compiler switches in the world are no substitute for simply throwing out bad software when a better tool comes along.

C was a "stroke of genius" at the time it was invented, and OK-ish in a very poorly connected world. As this article demonstrates once again, it's beyond fixable from a security perspective. All the new checkers and other fancy tools in the world will never be enough to fix a deeply ingrained culture, one where for instance performance is preferred over security almost every time.

It will be a very slow transition and projects like kernels which stand the most in critical paths will be last; but C will eventually and gradually fade away. It will happen much, much faster if/when some companies will finally be found liable for the security of the software they make money from - as opposed to be the first to market able to decode 4K videos on a 5" screen.

It took decades (one generation?) but even BIOS recently dropped assembly, so there is hope. At least for our children.

PS: of course alternatives to C are not silver bullets. They're "only" one or two orders of magnitude safer.

Kernel security: beyond bug fixing

Posted Nov 5, 2015 10:52 UTC (Thu) by Wol (subscriber, #4433) [Link]

> It took decades (one generation?) but even BIOS recently dropped assembly, so there is hope. At least for our children.

Which BIOS is that? I understood that at least one major BIOS was written in Forth, and has been that way for what, all of this century?

Cheers,
Wol

Kernel security: beyond bug fixing

Posted Nov 5, 2015 14:56 UTC (Thu) by ortalo (guest, #4654) [Link] (3 responses)

I do not really think the programming language is such a critical concern, neither the language level (Oz/ML vs Python vs C vs assembly language).
Why? Because it really seems possible to write a bad program in any language. And some people seem pretty good at that, whatever the programming environment cleverness.
And also because some of the best programs that never failed [1] were written in a mixture of assembly language and custom languages, but surely finely crafted by pretty good "coders" (who, btw, probably agree with you with respect to high-order languages safety advantage).

The problem when thinking about our children is the fact that you may neglect to assess what our grand-parents did (right).

[1] Look around Apollo or the shuttle flight system for top-class examples. Sorry for not having more recent examples. *That* is annoying I agree.

Kernel security: beyond bug fixing

Posted Nov 7, 2015 18:06 UTC (Sat) by geek (guest, #45074) [Link] (1 responses)

Well, TEX is written in Pascal and is widely held to be the best example of a large, widely used program with NO bugs.

And if it takes Ken Thompson and Dennis Ritchie to write large bug-free programs in C, um, how many programmers like that are there?

Kernel security: beyond bug fixing

Posted Nov 11, 2015 21:20 UTC (Wed) by robbe (guest, #16131) [Link]

I don’t think TeX being largely bug-free owns much to its implementation language.

A better explanation is that it’s in rigid bugfix-only mode for more than 20 years now.

Kernel security: beyond bug fixing

Posted Nov 9, 2015 2:16 UTC (Mon) by xman (guest, #46972) [Link]

> Because it really seems possible to write a bad program in any language. And some people seem pretty good at that, whatever the programming environment cleverness.

While undeniably people are great at writing bad code, there are languages/interfaces/apis/designs/whatever that are less error prone than others, and make it easier to see and correct bugs once you find them. Sparse demonstrates that even relatively subtle enhancements to the expressiveness of the kernel's code, you can significantly reduce the overhead lost to bugs.

That allows for a much, much more targeted approach to addressing security.