https://www.youtube.com/watch?v=aMkCKeZ8xZw
All the available videos from the Linux Security Summit are listed here:
Patch and release only works against inept opponents, and there are more non-inept opponents. It won't work against opponents who can develop or buy their own exploits. Patch and release gives the illusion of working because it stops vast numbers of inept attacks from clowns who just want to send spam emails.
Someone in military base security once said that you have to avoid tying up too much of your resources chasing kids throwing rocks at the perimeter fence. The real threat is the janitor who has access to the spare parts stores. Patch and release, and pattern-matching virus scanners, are chasing kids throwing rocks.
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?
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.
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”)