Hacker News new | past | comments | ask | show | jobs | submit login

It's interesting to see this laser focus on a particular kind of user. If you're running Linux on a server, you're a user, but unless you're very irresponsible you would probably rather your programs crash than give away private information. Your interface is to a cluster of machines where individual crashes are probably not that big a deal.

If you're running Linux via Android, you're a user, but mostly you're a user of actively developed apps on top of an actively developed OS, usually pegged to specific kernel versions. Your interface is to that layer on top, and given that its code is written by app developers and hardware vendors who will ship anything that doesn't crash, you probably want security bugs to crash.

It seems to me that the kind of user Linus means when he talks about "the new kernel didn't work for me" is a user of Linux without any substantial layers on top, where kernel updates happen more often than userland software updates, and where individual crashes have a significant impact. In other words, users of desktop Linux.

But I wonder if that focus on desktop Linux really reflects the majority of users. And, if not, perhaps it might make sense to have "hardening the Linux kernel" as the first step if it makes "raise the standard for the layers built on top" the endpoint.




>you would probably rather your programs crash than give away private information

Crashing on a security issue is a good thing for every kind of user. Crashing on a latent bug that COULD be exploited (maybe not possible at all) is a totally not desirable situation. The problem here is that hardening methods lack the ability to make that distinction.


> Crashing on a latent bug that COULD be exploited (maybe not possible at all) is a totally not desirable situation.

How do you square this with the reality that "keep on truckin" is generally the path from bugs to security exploits, and has been shown to be over and over in the wild?


Bugs will happen, that's a natural law of computer science, if you keep on trucking over them you will be delivering buggy software that is likely to cause problems. Even if you chase them down and correct them all, your software is still going to have bugs, that's a fact of life.

Should code containing bugs be allowed to run? If the answer is no we must ask ourselves how much software we have today that is completely bug free (that will be 0%).

I still think these proactive approaches are good to disclose possible exploits, but killing processes just because they might be exploitable is a very long shot.


And yet one of the big complaints about Windows of old was how often it crashes.


Crashing randomly for no good reason isn't the same thing as crashing on a security exception.


One of the point of Linus is that most of the crashes will not be because of an active attack but because of a possibly latent bug that sometimes appear and might very well be non exploitable. So probably people running server would like to have everything working instead of having random crashes on processes or drivers that are not the core of your service but can affect it. And given the size and complexity of the kernel it would not be strange to have these crashes appear only on certain setups and not necessarily on the ones of the people that are testing it first.


Sadly, fault-tolerant clusters where you can tolerate the loss of a single machine aren't the norm.

There are many (MANY) server applications or industrial use cases that do not handle random kernel panics very well.

I still prefer "crashing" over "silently ignoring critical errors", but you cannot generalize it like that.


I don't think this is fair characterization.

Errors are less likely to be actual exploits in servers too. When the kernel panic is caused by faulty driver failing network hardware, or user land software failures, it can take down multiple servers or all of them at once.

Most of the information in servers is private but not sensitive. You don't want anyone have access, but correct functioning and security warnings are more important than maximum information lock down.

btw. I don't see reason for not having kernel option to turn warnings into kernel panics.


It’s not even desktop users; most desktop users download Ubuntu and never touch anything, on reasonably common PC hardware. Kernel regressions mostly get caught in the Ubuntu betas or testing tracks (e.g. Debian Sid).

The typical user the kernel developers focus on here is a kernel developer: always running the latest kernel with a stable user space. I find it extremely narcissistic that they reject security improvements for billions of devices, for what essentially just makes developers lives easier,




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: