Unsafe at any clock speed: Linux kernel security needs a rethink

His point is that cars used to be built assuming there would never be an accident. They were very comfortable until you crashed into something, and then everyone died. Today cars are built defensively, so that when the unforeseen happens, you are still protected.

That's the idea. Building in defenses that protect you against unknown bugs and exploits.

If you want to think of this in the car safety analogy then consider all possible ways of killing someone in a car before and after the changes in safety standards. In the bad old days random events could kill you but if you had a targeted attacker they could use the same techniques and just drive a car into you, or force you into a wall. Now with newer safety standards the chance that a random event would kill you is much reduced, but the targeted attacker (assuming they don't just fire a bunker buster at you) needs to spend time researching the type of car, finding weak points, developing something to exploit those weak points etc.

So it goes with exploit mitigations. It wasn't that long ago that running a fuzzer on a product (and sadly fuzzers are still useful) would yield a massive amount of trivially exploitable bugs. These days, not as much, at least in mature platforms. You could think of the fuzzer discovered "random" bugs to be the case exploit mitigations are trying to protect against (re random collisions which car safety protect against). Even the simplest stuff like stack cookies make exploitation significantly harder. Are there no stack overflow bugs? Nope they still exist. Are they completely unexploitable? Nope, especially in the hands of a skilled attacker. Are you protected against randomly introduced bugs which cause a stack overflow and have a low chance of having some useful behaviour which makes them exploitable? Absolutely.

Honestly if someone _wants_ to _kill_ you I'm sure they could. If the attacker is willing to spend the time, effort and money to find better, more exploitable bugs and you're a target worthy of their efforts then you're screwed no matter what exploit mitigations you put in place (this is why imo bug hunting still has some semblance of value). But are you _that_ important? Would the FBI be willing to a throw a $1m iOS exploit at you for example?

The adversary is out of the picture here - you want to write your kernel in a way that makes accidental bugs hard/harmless. (i.e. prevent “random crashes”)

If that is so, then the vulnerability described is likely to be an issue, perhaps later, perhaps sooner, but within some given time frame during which the ubiquity of the 'net will be ever expanding.

Perhaps the solution is to guide the users in some very 'user' friendly adaptation of a 'man. page' that describes with elegant confidence the methodologies germane to creating a keycode that would allow for said 'users' to give themselves the safety from the perchance nefariously driven 'code poets' who would otherwise be able to derive social insecurity from whatever access might be available to them.

Long winded reply to say we need to not think about stoppping using Linux, but instead use a nice little intro for those who don't know enough (or even very little) regarding how to code a patch in their own kernel.

Given that the tech will be integrating NLP more and more, I could even imagine a 'talk through' with some 'Ask Jeeves'-esque personal assistant.

The whole thing is essentially a trust issue. Who's writing the code and who's debugging it to give all of the nUbs (yes, I use the old abbrev.) enough insight to give a little polish and shine to their appliances and machines.

Whew, lotta writing there :d

This has nothing to do with non-programmers.

Those measures are meant to protect user space, not the kernel.

but I think Linux is more than the kernel. If you break user land assumptions about filesystem layout, shared libraries, permissions, etc - are you in a better place as a 95% Linux with better security? From experience people aren't very happy with partial measures to make things linux like.

If you use the MS model (I really wish they had taken posix more seriously 20 years ago), you inherit all of Linux as model, with a different implementation.

If you leave the user/kernel boundary intact, have you improved the state of the world? To what extent are the security issues a result of the model and to what extent the implementation?

In a cell phone? Sure, because the replacement process is a somewhat annoying sales appointment at $carrier. In a thermostat? No, because it should last years. Maybe decades if it's a good one. IoT falls apart in this arena because the hardware is designed to be replaced often, and that's exactly what house hardware should not be.

And if the software is too complex, then don't do it. Do it right or don't bother.

If an engineer builds a bridge and it falls down, s/he will get punished for it.

If a doctor or a lawyer makes a similar hard mistake, s/he will get punished for it.

The same needs to happen to software engineering, specially given that in most countries software engineering is a degree with the respective Engineering Order.

Any Linux user is free to use whatever distro they want. Once you've chosen a flavor of Linux, in theory you could even run your own apt/rpm repository. There is no requirement that a Linux user must trust some third-party or their system won't run. Let's keep it that way :)

Linux has LTS support for 15 years. WinXP was supported for 13 years.