> From a security standpoint, when you find an invalid access, and you mitigate it, you've done a great job, and your hardening was successful and you're done.

> From a security standpoint, when you find an invalid access, and you mitigate it, you've done a great job, and your hardening was successful and you're done. "Look ma, it's not a security issue any more", and you can basically ignore it as "just another bug" that is now in a class that is no longer your problem. So to you, the big win is when the access is _stopped_. That's the end of the story from a security standpoint - at least if you are one of those bad security people who don't care about anything else. But from a developer standpoint, things _really_ are not done. Not even close. From a developer standpoint, the bad access was just a symptom, and it needs to be reported, and debugged, and fixed, so that the bug actually gets corrected. As a developer, I do want the report. But if you killed the user program in the process, I'm actually _less_ likely to get the report, because the latent access was most likely in some really rare and nasty case, or we would have found it already. I dont think Linus has an invalid point there. Taken from his previous thread - https://www.spinics.net/lists/kernel/msg2540934.html https://www.spinics.net/lists/kernel/msg2540934.html > Don't bother with grsecurity. Their approach has always been "we don't care if we break anything, we'll just claim it's because we're extra secure". He is worried that grsecurity does not play nice with the kernel in a way of "let's make security hardening obsolete by fixing bugs in the kernel".