Live data from Hacker News

Linus Torvalds: “Do No Harm”

lkml.org

141–150 of 233 posts

Re: Linus Torvalds: “Do No Harm”

#141

Earlier quoted context omitted.

Lots of drivers on Windows, OS X and Linux run in kernel space simply because kernel-to-user-and-back context switches are expensive and so kill performance. I believe the exceptions are printer and scanner drivers (these run in user-space CUPS in OS X/Linux), some filesystem drivers (basically, FUSE-backed) and cheap-ish USB drivers.

The logic behind why it is done like that I get. Just wondering as You said is it possible to push at least the most bug-prone and exploitable ones to user-space

The "most bug-prone an exploitable" dimension is a bad one. There's probably some correlation, but it is not a good way to look at the differences.

You can push into userspace the software that work some data into some low level data. You can't push into userspace the IO of that low level data to the hardware. If your driver is mostly interpreting complex data before IO, you can push most of it into userspace, but if it is really doing IO (or calculations are interspersed with IO), you can't.

Re: Linus Torvalds: “Do No Harm”

#142

Earlier quoted context omitted.

Let's say somebody gives you an USB stick and you plug it into your laptop. Which of the following scenarios would you like to see? 1. 0-day in the kernel's USB code. You're part of stuxnet now. 2. 0-day in the kernel's USB code. You're part of stuxnet now. You also get a message that tells you how and where to report the bug that was exploited. 3. 0-day in the kernel's USB code. Your computer crashes. You're not par…

The problem is, what actually happened (in a previous commit) was: The IPv6 stack does a perfectly sensible and legal thing. The hardener code misunderstands the legal code, and causes a reboot. That it was Linus is worried about -- often it is hard to tell the difference between "naughty" code which can never be a security hole, and genuine security holes. They should all be fixed ASAP, but making code that previous…

Bugs in the hardening code are obviously bad and annoying but that's besides the point. All bugs are bad and annoying, especially ones that cause a kernel panic. I don't think anybody is going to argue with that.

That's not what Linus said though. What he said is:

    > when adding hardening features, the first step should *ALWAYS* be
    > "just report it". Not killing things, not even stopping the access.
    > Report it. Nothing else.
and:

    > All I need is that the whole "let's kill processes" mentality goes
    > away, and that people acknowledge that the first step is always "just
    > report".
"Not killing things, not even stopping the access." Oh boy.

Re: Linus Torvalds: “Do No Harm”

#143
post #134

Earlier quoted context omitted.

Corrupting SP is part of almost every exploit and I can guarantee you that it is very likely (going to cause harm on your system). Try to pull Metasploit GIT repo to get some idea about thousands of payloads that do corrupt SP without crashing the host...

Yes, but how many of all cases of corrupted stack pointers are exploits?

Why would that matter? We're not trying to be secure against random cosmic rays. We're trying to be secure against attackers.

http://wondermark.com/406/

Re: Linus Torvalds: “Do No Harm”

#144
post #63

I wrote the email that prompted this quite civil response. I'm very pleased with the outcome, because I think this clear statement of his position is a lot more useful for people to work with, rather than just assuming Linus hates security or something. I interpreted his response in practical terms as essentially being the following. Patch set merge 1 has "report" as default and "kill" as a non-default option. Patch…

I interpreted the mail as (among other things) "killing processes is not acceptable behavior", or at least not acceptable default behavior.

Re: Linus Torvalds: “Do No Harm”

#145

Earlier quoted context omitted.

Apps are supposed to keep their state either by saving your work regularly to persistent media or keeping your data off-client. We're living in 21st century in a cloud era FFS. Keep running your app although integrity corruption within the application happened is putting user data at risk. IMHO an application that corrupts 3 days long presentation file save is to every user more frustrating than the one that crashes…

Meta: Who, and why, flagged this comment? What rule exactly Slavius breaks here? On topic: I can't recall now the details, but I read a paper once about a system which had no shutdown procedure at all, the only way to exit it was to crash it somehow or just shutdown the computer. The system made sure to save everything often enough and made sure to store the data in ways which allowed for restoring possibly corrupted…

You might be thinking of KeyKOS, and of the anecdote which can be found at https://lists.inf.ethz.ch/pipermail/oberon/2010/005734.html (it should also be at the EROS homepage, but it's down for me at the moment).

See also: "Crash-only software" https://lwn.net/Articles/191059/

Re: Linus Torvalds: “Do No Harm”

#146

Earlier quoted context omitted.

The problem is, what actually happened (in a previous commit) was: The IPv6 stack does a perfectly sensible and legal thing. The hardener code misunderstands the legal code, and causes a reboot. That it was Linus is worried about -- often it is hard to tell the difference between "naughty" code which can never be a security hole, and genuine security holes. They should all be fixed ASAP, but making code that previous…

Bugs in the hardening code are obviously bad and annoying but that's besides the point. All bugs are bad and annoying, especially ones that cause a kernel panic. I don't think anybody is going to argue with that. That's not what Linus said though. What he said is: > when adding hardening features, the first step should *ALWAYS* be > "just report it". Not killing things, not even stopping the access. > Report it. Noth…

Step back a bit: when developing a new selinux policy, won't you develop first on permissive mode, and only after it's working without warnings, enable enforcing mode? It's the same thing here: the hardening should be developed first in a "permissive" mode which only warns, and then, after it's shown to be working without warnings, changed to be "enforcing" (in this case however, after some time the "permissive" mode can be removed, since new code should be written with that hardening in mind).

Re: Linus Torvalds: “Do No Harm”

#147
post #3

Background: the "kernel self protection project" (KSSP) recently upstreamed the Grsecurity/PAX reference counting implementation which prevents a certain class of security bugs from being exploited. Grsecurity is a security hardening patchset for Linux that makes deliberate trade-offs in favor of security, sacrificing availability if necessary. This, aside from the political issue, is the main reasons why it's hard t…

>If the large companies who use Linux really want to improve kernel security, they need to work with Grsecurity and not against them. It's beyond me how this isn't happening already.

It's more that Grsecurity is working against everyone else. They want to pretend the GPL works in a way that it doesn't so that they can sell their patches. Then they make threats to people who say "that's not how the GPL works" and distribute their patches in accordance with how the GPL actually works. That's not how kernel development is done. I'd rather have an insecure kernel than their bullshit.

Re: Linus Torvalds: “Do No Harm”

#148
post #3

Background: the "kernel self protection project" (KSSP) recently upstreamed the Grsecurity/PAX reference counting implementation which prevents a certain class of security bugs from being exploited. Grsecurity is a security hardening patchset for Linux that makes deliberate trade-offs in favor of security, sacrificing availability if necessary. This, aside from the political issue, is the main reasons why it's hard t…

>> This is exactly what you want if you care about security, but it's not a trade-off everyone is happy with (including Linus). Let's rephrase that. This is exactly what you want if you care only about security, or care about security above everything else - including your system running at all. People run software for reasons, and they need it to keep running for those reasons. The security folks are not really qual…

No, they really are. Don't confuse doing it poorly with the ability to do it.

Re: Linus Torvalds: “Do No Harm”

#149

Earlier quoted context omitted.

I see. It's ok because we'll just pass the buck and make it someone else's problem.

Let's say somebody gives you an USB stick and you plug it into your laptop. Which of the following scenarios would you like to see? 1. 0-day in the kernel's USB code. You're part of stuxnet now. 2. 0-day in the kernel's USB code. You're part of stuxnet now. You also get a message that tells you how and where to report the bug that was exploited. 3. 0-day in the kernel's USB code. Your computer crashes. You're not par…

This is exactly the kind of thinking Linus is talking about. In 3, I lost my work. Possibly very important work. To most people, being a part of stuxnet, while undesirable, is preferable to losing their work.

And you neglected a scenario 4: nobody is attempting to compromise my machine, but a buggy bit of USB code just crashed my system and took all my work with it.

Re: Linus Torvalds: “Do No Harm”

#150

Earlier quoted context omitted.

Say there's a minor error in a network driver. Yes, it might be exploitable by a smart person. But the error only triggers once a day when a counter rolls over. Do you really want your box to lock up and panic when this error is encountered, or do you just want your box to keep working. I'm firmly in the first camp (I'll take lock up and freeze thanks) but 99% of users don't care about a bug like that and just want t…

But do you want your box to send silently corrupted data for the next two years? Or would you rather reboot every night, and maybe escalate to your red hat support contract, where someone will then fix the underlying bug (for which you now have crashdumps),

That Redhat support contract won't save you from a bug in a binary blob network driver.

Crashing the whole kernel at the drop of a hat seems like a pretty extreme stance to take as a general policy IMHO. Killing and restarting the driver will usually suffice, although some data may be lost and have to be retransmitted.

Post reply on HN