Though, 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.

> 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.

I 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.

Depending on the bug class there may be users who never want "kill" to be the default option.

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:- )

It would be awesome if this could be set by a sysctl, instead of setting a kernel option and recompiling the kernel.

Patch Set Merge 1.5?

I interpreted the mail as (among other things) "killing processes is not acceptable behavior", or at least not acceptable default behavior.

Is 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.

You'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.

It'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

Nope, his first email in the thread was this:

https://lkml.org/lkml/2017/11/17/423

Where he's quite civil and explains quite clearly why he won't accept the patch, and what should happen for the patch to be accepted. The Kees's reply insisting on the merge is what led to the profanity-laden email, and frankly I understand that (not condone, but understand from a human-reaction point of view) - how many times does one have to iterate his viewpoint to others to make himself heard?

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/kernel/1711.2/01701.html

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 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.

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.