Kernel security: beyond bug fixing [LWN.net]

Kernel security: beyond bug fixing

Posted Oct 29, 2015 9:28 UTC (Thu) by mjthayer (guest, #39183)
Parent article: Kernel security: beyond bug fixing

> The kernel community has often been hostile to changes that increase security if they decrease usability or performance, or if they make development harder.

I have always found that programmers tend have a slightly irrational attitude towards performance. An extreme example would be added complexity to speed up code containing a bug which could cause a crash. The user gains a few cycles every time the code is executed, and loses work every time the crash occurs. What is the overall benefit to the user? But then again, perhaps what the programmer wants is not really performance but fun writing (and reading?) the code. Which is perhaps slightly more rational.

to post comments

Kernel security: beyond bug fixing

Posted Oct 29, 2015 10:21 UTC (Thu) by flussence (guest, #85566) [Link] (6 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.

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

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.

userspace drivers

Posted Nov 5, 2015 12:37 UTC (Thu) by Zolko (guest, #99166) [Link] (3 responses)

This performance -vs- speed is also the argument to not have drivers in userspace. Which means that there is kernel code running that is completely unknown to the developers. We are not talking about bugs or security flaws, but built-in backdoors by the manufacturer. For example, Broadcom is a US company, who wants to bet that their closed binary drivers contain backdoors requested by the NSA under gagging legislation ?

What use is there for a firewall if the first line of defense is a traitor ? What use is there for sandboxing if the X driver installs keyloggers and then phones home ?

Talking about kernel security with a monolithical kernel and binary drivers is pointless crap (TM Linus) !!!

userspace drivers

Posted Nov 8, 2015 12:43 UTC (Sun) by JanC_ (subscriber, #34940) [Link] (2 responses)

I don't see how those binary drivers being in userspace would help against an NSA backdoor at all (especially in case of e.g. network drivers)?

And I think you are wrong in case of most Broadcom drivers, which are open source but have to upload a closed source firmware into the network hardware, because they don't have a closed source firmware in ROM/flash like some others do. Both uploaded & saved in ROM/flash firmwares could contain a backdoor, so kernel vs. userspace doesn't even come into play there.

userspace drivers

Posted Dec 18, 2015 4:22 UTC (Fri) by Rudd-O (guest, #61155) [Link] (1 responses)

There's this thing called "Direct Memory Access" in modern computers. Drivers can use that to access any sort of main memory or other devices in the same bus.

Thus, while you think your (possibly compromised) network driver is oblivious to your password keystrokes because your connection to this site is SSL, your (possibly compromised) network driver is in fact stealing your keystrokes as you go.

(I say possibly compromised, but with DMA, it's a juicy target for a compromise. There are videos of people doing this sort of thing, by the way. It's not something esoteric.)

userspace drivers

Posted Dec 18, 2015 4:29 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> There's this thing called "Direct Memory Access" in modern computers. Drivers can use that to access any sort of main memory or other devices in the same bus.
Not anymore: https://en.wikipedia.org/wiki/Input%E2%80%93output_memory...

Kernel security: beyond bug fixing

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

It may seem like developers are insane about this, but when you contemplate just how much performance is left on the table with our security measures and abstractions right now, there is actually a LOT developers already have sacrificed on the pillars of performance.

With systems programming in particular, inefficiency itself often leads to its own bugs and security compromises farther up the stack. Developers *and* end users naturally route around inconvenient security systems and abstractions.

Heck, we can have drastically improved security and privacy on the Internet right now, if we're just willing to absorb a 5x increase in latency and decrease in throughput (which, if you think about it, we had to suffer with right now), but hardly anyone is willing to make that compromise.

At a higher level, the whole "remember my credit card" feature is an exercise in forgoing the minimal protections of an at least somewhat random and monitored credit card number that they carry with them everywhere for protection from what is almost always not-at-all-random and trivially crackable, not terribly well monitored, memorized password. Ask anyone who works in e-commerce how much more money they make with that feature.