Linus: Do no harm! Except against security people. I'd like to harm them a lot!
Linus Torvalds: “Do No Harm”
111–120 of 233 posts
Re: Linus Torvalds: “Do No Harm”
#112Earlier quoted context omitted.
...or is being remotely exploited and it silently succeeds. Who wants that?
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).
Stack pointer manipulation is the entry point for an extremely large subset of security issues.
Re: Linus Torvalds: “Do No Harm”
#113Earlier 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?
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…
For safety-critical systems, resetting on a fault is very much factored into the worst-case response time and expected behaviour.
PANIC on fault is exactly what you design into the systems.
What you find is that the truly safety-critical portion of the system is running on a microcontroller and the UI (which is not safety-related) can run on Windows or Linux.
Re: Linus Torvalds: “Do No Harm”
#114Earlier quoted context omitted.
> Most users would accept the trade off between crashed browser and infected/corrupted system. Most users are using computing devices a means of getting stuff done. They don't want to spend any energy thinking about how their software works, they want their devices to be invisible, which they use to run their Apps uninterrupted. The trade-off is whether to let Apps continue running vs hard crashing and taking down al…
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…
> Keep running your app although integrity corruption within the application happened is putting user data at risk.
If user data is continually backed up to a remote site it's not going to be at risk from a local bug is it? Bugs exist in all software, Users are going to be be more visibly frustrated from their Apps frequently crashing then the extremely unlikely scenario where a detected bug corrupts their "3 days long presentation". They're going very unhappy if the cause of their frequent data loss was due to a user-hostile setting to hard crash on the first detectable bug.
> Microsoft have invented "Application Recovery and Restart" exactly for this purpose.
From Microsoft website:
> An application can use Application Recovery and Restart (ARR) to save data and state information before the application exits due to an unhandled exception or when the application stops responding.
- https://msdn.microsoft.com/en-us/library/windows/desktop/cc9...
i.e. restarting Apps due to "unhandled exception or when the application stops responding" in which case the App is in an unusable state and ARR kicks in to try auto recover it for minimal user disruption. The focus on providing a good UX, not a miserable crash-prone experience where users use their devices in fear that at anytime anything they're working on can be terminated abruptly without warning.
Re: Linus Torvalds: “Do No Harm”
#115Earlier quoted context omitted.
Hooold it. Some of those things are not like the others. -- I pity the engineers working on ventilation machines and the like. Medical devices are insanely hard to get right; that's neck and neck with aviation testing. I'm reminded of SQLite3's "aviation-grade" TH3 testsuite, which apparently has 100% code coverage. Let's be honest; Linux's monolithic design can't really attain that. I would never use Linux for a med…
Many medical devices run Linux. Most (AFAIK) patient monitors run Linux; GE and Philips (the biggest is business) both run on Linux. Those are the devices that keep you alive during surgery, make sure that those who are born too early (I don't know the English term here) are doing ok, monitor you state while you are in ambulance etc.
No...
Many medical devices run Linux as a User-Interface... (or Windows for that matter).
The actual safety-critical portion of these systems is rarely running Linux, but rather on a bare-metal micro.
Re: Linus Torvalds: “Do No Harm”
#116Earlier 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…
Hooold it. Some of those things are not like the others. -- I pity the engineers working on ventilation machines and the like. Medical devices are insanely hard to get right; that's neck and neck with aviation testing. I'm reminded of SQLite3's "aviation-grade" TH3 testsuite, which apparently has 100% code coverage. Let's be honest; Linux's monolithic design can't really attain that. I would never use Linux for a med…
Erlang's error-handling model is good (and interesting). Th e motto is: "Let it crash".
Each node does not handle errors at all, but PANICs on a fault. It is up to the supervisor (with global knowledge and state) to handle the fault appropriately.
Re: Linus Torvalds: “Do No Harm”
#117Background: 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…
> 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.
Re: Linus Torvalds: “Do No Harm”
#118I 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…
The other important "users" are the developers and drive-by-developers of those user space processes which may accidentally trigger these bugs. These folks are highly likely to be able to resolve these issues if they are reported [in a way which is visible to them].
Counterpoint: most developers and users are not actively following their logs at any level, and maybe something should be done to make it more common. Possibly stderr logging of such errors in libc (or some other commonly used library which already sometimes logs errors on its own, like glib). 3:- )
Re: Linus Torvalds: “Do No Harm”
#119Earlier 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…
First things first: Kernels panic and processes crash. If your medical equipment or telco/ISP system can't recover from that then you're in trouble anyway. Why they crash doesn't really matter in that context. As far as voting machines go, kernel panic sounds waaay better than executing malicious code. > Imagine a security f*ck up, like Heartbleed, but this time with an option to halt kernels / systems. IIRC heartble…
I see. It's ok because we'll just pass the buck and make it someone else's problem.
Re: Linus Torvalds: “Do No Harm”
#120It'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…
>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.
And yet one of the big complaints about Windows of old was how often it crashes.