Rethinking Linux Kernel Security

> "we have to change the way we approach this dramatically, the same way that vehicle manufacturers in the 1970s did."

I think he's probably right. It might be interesting to build the kernel (or more realistically, a new distro) with some of its recent lxc/sandbox features as opt-out rather than opt-in.

> "people are finding these bugs sometimes immediately when they're introduced."

How do we know this is the case?

>"I hear a lot of blame-shifting of where this problem needs to be solved," he told the audience. "Even if upstream says 'oh sure we found that bug, we fixed it,' what kernel version was it fixed in? Did it end up in a stable release? Did a vendor backport it? Did the carrier for the phone take that update from the vendor and push it onto phones?"

IMO this is not the kernel maintainers' role. A curator like The Linux Foundation might be appropriate to shepherd critical fixes somehow. But ultimately downstream consumers bear the responsibility to accept new patches and schedule them in their own release cycle. If the linux kernel could offer anything, it might be some kind of smaller-scope upgrade feature. If each of the syscalls, VFSs, block devs could be individually patched without downtime, maybe that would somehow make for a lower-risk upgrade.