151–160 of 233 posts
Earlier quoted context omitted.
I want both. Panic in a test/development kernel, do not panic in a production environment.
Absolutely panic in a production environment. Potential data corruption is far worse, so is a potential security compromise.
E.g. performing industrial control automation or airplane rudder control in a completely segregated network.
You want control over these tradeoffs, not hardcoded behaviors.
Earlier quoted context omitted.
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/
Earlier quoted context omitted.
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 th…
Earlier quoted context omitted.
If your security patch kills users' buggy processes or even crash their systems then you are a «bad security person». Please report the bad access first so users and developers of their software have time to fix the bug. Upgrades disabling users' software are a big no-no. After all security is meaningless for a non-working system.
Linus has been pounding on the bench saying "Don't Break Userspace" for over two decades now. This is really just another manifestation of that same policy. Some 'security' folk apparently believe they occupy a special place in which they are exempt from this policy. Linus is showing them they're wrong; evolving the kernel into a minefield in the name of security is not the way to world domination.
So they'll be secure from a hypothetical possible bug today, and completely vulnerable to real demonstrated security exploits in the future.
Earlier quoted context omitted.
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.
The OS[1] I've been talking about was primarily concerned with a single-machine environment, which resulted in slightly different design.
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.
The kernel (for my intended usage) should intentionally panic only if there is a risk of corrupting my .tex files.
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…
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…
Light on details, but the vulnerabilities are disclosed and fixed [0]. ME updates are already available from many OEMs.
[0] https://security-center.intel.com/advisory.aspx?intelid=INTE...
Earlier quoted context omitted.
Linus' response is that calling it an infeasible problem is a cop-out. The right way to go about it is to fix them all, incrementally if need be, and not break userland in the process.
These comments sound analogous to real world security and societal issues. Like, the desire to increase army size and addressing the underlying issues. One is a short term solution, the other long term.
Earlier quoted context omitted.
>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?