Earlier quoted context omitted.
Why isn't Grsecurity publicly available anymore?
https://grsecurity.net/announce.php Reading between the lines, it seems to be a money thing.
Sigh. Tragedy of the commons.
Linus Torvalds: “Do No Harm”
181–190 of 233 posts
Re: Linus Torvalds: “Do No Harm”
#182Very pragmatic. He sees software in the overall context of getting a job done with a computer, imperfect though it may be, instead of dying because it was not perfect. Unlike a segfault from a user space program that indeed merits a 'kill', the kernel should strive at all costs to keep running, since kernel panics are so much more inconvenient.
Absolutely not. If “do no harm” is a principle, then the kernel should ensure that no harm is taking place. If flaws within the kernel allow harm to occur while otherwise normal transactions are occurring then it is absolutely preferable to panic and shut down over allowing that potential harm to occur. To suggest otherwise, that detected errors that allow harm should be allowed, is pure insanity. Linus is unquestion…
You mistake "do no harm" for "don't let the user do harm". This is "do no harm" in the sense that Hippocrates said it; your job as a kernel security dev is to not harm the user, just as a doctor's job is to not harm his patient.
Re: Linus Torvalds: “Do No Harm”
#183Earlier quoted context omitted.
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…
Sadly this kind of magical security thinking have many proponents higher up in the Linux stack, and they have the backing/support of GKH. Thus i worry what will happen the day Linus give up the reins.
I honestly don't think Linus will give it up until he's in a box. He lives and breathes the kernel.
Re: Linus Torvalds: “Do No Harm”
#184I 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…
It would be awesome if this could be set by a sysctl, instead of setting a kernel option and recompiling the kernel.
Re: Linus Torvalds: “Do No Harm”
#185Earlier quoted context omitted.
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.
So why is not the world running on C64s?
The world does run on microcontrollers that have roughly the same processing capability as a c64...
The vast majority of processors sold are not i5 or i7 level but microcontrollers.
Re: Linus Torvalds: “Do No Harm”
#186Earlier 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.
On the other hand, the mere act of panicking may corrupt data (by virtue of stopping processes). I learned this the hard way when my kernel panicked while I was shrinking a large ext4 volume (the panic was unrelated to the shrinking). It's not just a simple equation like you've claimed.
Re: Linus Torvalds: “Do No Harm”
#187Earlier quoted context omitted.
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…
There rule I work to when I design these type of systems is that if the source of the error is internal you should reset and avoid propagating the error.
Conversely if you receive an error from an external source you should handle it gracefully and reject the bad message.
Re: Linus Torvalds: “Do No Harm”
#188No security person is likely to argue that DOS attacks aren't a security issue. They get CVEs all the time! A patch that denies the user the ability to use the service introduces a security issue. Bad usability IS a DOS attack.
Re: Linus Torvalds: “Do No Harm”
#189"Without those users, your system may be "secure", but all your security work was still just masturbation. You didn't do anything useful at all in the end."
Amen. Linus has been consistent with his views on security, and this is just an elucidation of a process that reflects those views. [1][2][3]
[1] https://lkml.org/lkml/2008/7/15/296
[2] https://www.cio.com/article/2973995/linux/linus-torvalds-sec...
Re: Linus Torvalds: “Do No Harm”
#190Body for this message unavailable
Cache: https://web.archive.org/web/20171122005241/https://lkml.org/...