Kernel.org's road to recovery [LWN.net]

Kernel.org's road to recovery

Posted Oct 17, 2011 1:09 UTC (Mon) by raven667 (subscriber, #5198)
In reply to: Kernel.org's road to recovery by PaXTeam
Parent article: Kernel.org's road to recovery

3. you haven't explained what 'all of the fixes' means. you and others already said that *everything* not proven otherwise is a security fix therefore the same everything must be backported by everyone who cares which in practice is possible only by following linus's git HEAD. i bet even you don't dare to do that to your company's servers (i actually wonder what you do given that you don't use -stable either).

I don't know if you pay attention to kernel development but from my understanding running the latest Linus kernel release is what is recommended to have all the fixes. I'm sure there are some people who _do_ run raw Linus kernels who want the latest fixes as soon as they are out of the oven. The current Linus kernel certainly has more security relevant fixes than any vendor kernel which only has backports as the very nature of cherry picking backports is going to miss security fixes which aren't known at the time the fix is made. That is what the kernel release announcements recommend.

Many people think running the latest kernel.org release is potentially too disruptive due to other changes unrelated to bug and security fix work. Unfortunately trying to separate feature from fix work didn't work as a process from the kernel developers perspective which is why the development process was changed in the transition from 2.4 to 2.6 so that feature and architectural changes are fed right into the main line of development.

I think that the major vendors (RedHat, Debian, SuSE, various embedded, etc.) should continuously re-evaluate how close they can run to the main line of kernel.org kernels rather than trying to cherry pick backports and maintain their own "stable" forks. Ideally the regular kernel releases would be equivalent in stability and superior in security than the current situation.

(Log in to post comments)

Kernel.org's road to recovery

Posted Oct 17, 2011 6:53 UTC (Mon) by malor (subscriber, #2973) [Link]

Unfortunately trying to separate feature from fix work didn't work as a process from the kernel developers perspective

And that, right there, is the single core problem with Linux security.

Security is hard. It means more pain during development. Separating fixes and features is a pain in the ass. But if it doesn't get done, you end up in the snarl they're in now.

Even the developers themselves can't provide secure shared access to a single Linux kernel image. How can anyone else expect to?

Kernel.org's road to recovery

Posted Oct 17, 2011 7:28 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

the problem is that one person's 'bugfix' is another person's 'new feature'

especially when the bugfix can end up refactoring the code in the process.

yes, this is a big problem with Linux, but the rate of fixes (of all kinds) is the great strength of Linux. At this point nobody knows how to fix the weakness without giving up the strength. There are other OS groups (openBSD comes to mind) that seem like they follow the philosophy that you are advocating, but despite the fact that they had several years of a head start on Linux, their development models have caused them to be far less useful on current hardware. (and therefor any security benefits they may provide, far less useful)

I don't understand your comment about the kernel developers being unable to provide shared access to a single kernel image.

are you referring to the fact that there was a privilege escalation vulnerability on kernel.org? if so, any conclusions about what the problem was need to wait until we learn what happened. And in any case, the vast majority of the kernel developers were not involved in administering the systems (and note that it was several systems, not a single system)