5 ms·
I 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
by zx2c4 9y ago
I 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 set merge 2 has "kill" as default and "report" as a non-default option. Patch set merge 3 removes support for "report". This way we have the best of both worlds: we eventually reach the thing that actually adds real security benefit, which makes security folks happy. And we don't break everybody's computers immediately, allowing time for the more obvious bugs to surface via "report", which makes users and developers happy. Seems like a reasonable process to me.
- zaarn 9y agoThough, I think that the time between PSM1 and PSM2 will be significant. Usually default options are changed once basically all distros compile with another option without widespread breakage. And once no LTS kernel with PSM1 is supported, you merge PSM3. Might take years but atleast the airplanes keep flying instead of crashing their computers and consequently themselves.
- zx2c4 9y ago> Though, I think that the time between PSM1 and PSM2 will be significant. Indeed you're probably right there. Fortunately security-focused distributions and individuals would be able to change the defaults in the interim.
- shandor 9y agoI think the most important point here is that with those different patch sets, the more security-conscious users/companies get to have the properly hardened version immediately into use, rather than running the "only report" versions for what might be years, as you say. Granted, I'm looking at this from a perspective where our company compiles our own kernel for use in embedded devices, so we can have whatever patch sets supported we want. But I think that's much better than everyone having to use the "report only" patches for years, or even worse, the features never getting into the kernel in the first place.
- mpe 9y agoDepending on the bug class there may be users who never want "kill" to be the default option.
- azernik 9y agoIt'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 https://lkml.org/lkml/2017/11/17/767
- avinassh 9y agoNope, this is the first email - http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01357.html 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 http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01325.html 2 - http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01357.html http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01357.html 3 - http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01368.html http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01368.html 4 - http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01636.html http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01636.html 5 - http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html
- FussyZeus 9y agoNormally 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.
- digi_owl 9y agoSadly 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.
- mtgx 9y agoIs that really a position Linus has maintained for a long time? Because I got the feeling Linus really just hated anything to do with security. It's only in more recent years when the automotive and IoT industries have started to get involved in the Linux Foundation and them asking for more security features that he seems to have tried to find ways to "compromise" with security people.
- forgottenpass 9y agoYou're going to get a very different perspective depending on if you actually lurk lkml or just read when something gets linked by socail media or "news" that needs to wrap it in a hot take to make lookies loos interested in lkml.
- microcolonel 9y agoThe 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:- )
- perlgeek 9y agoI interpreted the mail as (among other things) "killing processes is not acceptable behavior", or at least not acceptable default behavior.
- jlgaddis 9y agoIt would be awesome if this could be set by a sysctl, instead of setting a kernel option and recompiling the kernel.
- edoceo 9y agoPatch Set Merge 1.5?