
Rethinking Linux Kernel Security - zmanian
http://arstechnica.co.uk/security/2016/09/linux-kernel-security-needs-fixing/
======
wyldfire
> "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.

