Live data from Hacker News

Linus Torvalds: “Do No Harm”

lkml.org

131–140 of 233 posts

Re: Linus Torvalds: “Do No Harm”

#131

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),

What data exactly is being corrupted?

Fail fast is a great philosophy for end-user software. But it is not that strictly good for middleware, and is almost certainly wrong for a kernel.

Re: Linus Torvalds: “Do No Harm”

#132

Earlier quoted context omitted.

The person at the other end of the conversation would disagree with this sentiment: "Thanks. Still, I'd prefer Linus yell at me than other folks trying to do similar work. If I can shield anyone from this abuse, then maybe they won't give up on kernel security development. Digging Linus's actionable feedback out of the ad-hominem attack can be challenging." [1] [1] https://twitter.com/kees_cook/status/932694978366619…

>Digging Linus's actionable feedback out of the ad-hominem attack can be challenging. They're not really that separate. He's being totally disingenuous and still letting his own fragile ego get involved.

> He's being totally disingenuous and still letting his own fragile ego get involved.

Who is?

Re: Linus Torvalds: “Do No Harm”

#133
post #83

Earlier quoted context omitted.

Linux is used in so many critical systems. What happens when a security bug stops the ventilating machine of a person lying in hospital bed, or halts the screen of a surgeon. Not to mention voting machines, ISP's, telecoms. For me having all those stopped, when properly exploited, looks more like a very scary DoS attack vector. Imagine a security f*ck up, like Heartbleed, but this time with an option to halt kernels…

> Linux is used in so many critical systems. It shouldn't be. It's ill suited for that. Look at seL4, minix3, echronos instead.

Well apparently even minix3 is not free from critical vulterabilities ;)

https://security-center.intel.com/advisory.aspx?intelid=INTE...

Re: Linus Torvalds: “Do No Harm”

#134
post #76

Earlier quoted context omitted.

That is very unlikely. Crashing would happen 100% of the time though. Most people want that trade-off (meaning: If their browser would crash, they would switch to another one, even it was less secure).

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?

Re: Linus Torvalds: “Do No Harm”

#135
post #94

Earlier quoted context omitted.

It's only civil because it's a follow-up; usually it's only his first email in a thread that follows the classic (notorious?) Torvalds style. For those who want it, here's his first email in the thread, profanity and all: https://lkml.org/lkml/2017/11/17/767

Nope, this is the first email - http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01357.html Entire thread links from start: 1 - http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01325.html 2 - http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01357.html 3 - http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01368.html 4 - http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01636.html 5 - http://lkml.iu.edu/hypermail/linux/k…

Normally I'm not a fan of Linus, but this:

> IT IS NOT ACCEPTABLE when security people set magical new rules, and then make the kernel panic when those new rules are violated.

> That is pure and utter bullshit. We've had more than a quarter century _without_ those rules, you don't then suddenly walz in and say "oh, everbody must do this, and if you haven't, we will kill the kernel".

> The fact that you "introduced the fallback mode" late in that series just shows HOW INCREDIBLY BROKEN the series started out.

This makes perfect sense and outlines a real problem with security patching in general.

Re: Linus Torvalds: “Do No Harm”

#136

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…

The flagger probably was uncomfortable with "FFS". After all colorful expression is bad for HN. b^)

What you're talking about seems like crash-only with Erlang/OTP.

Re: Linus Torvalds: “Do No Harm”

#137
post #62

Earlier quoted context omitted.

I want both. Panic in a test/development kernel, do not panic in a production environment.

It the opposite... you should panic in a production environment and reset the state of the machine (which has become indeterminate). The correctness and validity of the data >> uptime.

As so often, it really depends. Let's say you've just detected that you're going to send incorrect data because you've ended up in an indeterminate state.

If the remote end is going to ignore that data anyways, would it really be such a bad idea to keep running? Do you really want to go down in order to ensure that a remote who's ignoring your data can get correct data to ignore?

Of course you never know what sort of effect the corrupt data is going to have, so it's always hard to make that decision.

Like that issue with libraries linking against objective-c frameworks that has crept up with High Sierra and broke most of the Ruby world: Yes. The usage was incorrect. Yes, forking after threads are launched leads to undefined behavior, yes, knowing about it is a good thing.

But: So far the crashes have been rare in the common use-cases (or they would have been fixed), so High Sierra's change to blow up loudly when it detects the misuse has actually caused a lot of trouble for people where things worked fine before.

To the point where many Ruby developers were complaining about High Sierra "breaking" their workflow and recommending against upgrading.

The new check is totally justified though. The existing forking behavior was wrong and it could have lead to crashes down the line. It didn't though. And now people are forced to fix something that was never an issue to begin with.

It's a fine line to walk and while I generally prefer things to blow up as they go wrong, sometimes I catch myself wishing for stuff to just continuing to work.

On some self-reflection, I come to the conclusion that I want my cake and eat it too.

Re: Linus Torvalds: “Do No Harm”

#138
post #8

Earlier quoted context omitted.

> Grsecurity will rather terminate userland programs or, in some rare cases, panic the kernel if it finds itself in an undefined state. This is exactly what you want if you care about security, but it's not a trade-off everyone is happy with (including Linus). I'd also like my kernel to halt whenever an assertion does not hold, for the sake of keeping my sanity; not just for security. Why would you not want this?

A better way of course is not to halt on assertion, but to limit the scope of any potential problem in a such way, that an assertion could only crash a tiny isolated thing and trigger its restart, possibly not impacting availability whatsoever. You still get your sanity, but also get users happy with a rock solid thing that just works even in a presence of errors. The idea is known as supervision trees.

I think a good tradeoff could be that with containers, the individual containers are hardened, whereas the kernel's host OS is not. The host OS doesn't do much except keeping the containers running.

Re: Linus Torvalds: “Do No Harm”

#139

"without users, your program is pointless, and all the development work you've done over decades is pointless. .. and (then) security is pointless too, in the end." He tends to get really mad when kernels dev inconvenience user space devs. Perhaps one of the reasons Linux succeeded was because of this fanatical customer focus - if linux is the platform, user space developers are the customers.

This. Not breaking user space is fundamental to the success of most operating systems today. I read this article I cannot seem to find about Microsoft employees spending months replicating "wrong" behavior in so that applications still ran on . Users don't want to see their applications crashing. I wish I could find this article again, it's very relevant to your comment.

It reminds me of the hack Microsoft did to make simcity work in Windows 95. https://news.ycombinator.com/item?id=2281932

Re: Linus Torvalds: “Do No Harm”

#140

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…

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 previously worked make a user's computer reboot, when it is perfectly fine, is not a way to make friends.

Post reply on HN