3 ms·

It's been "corrupting data" for 20 years now. What's worse: the 21st year of corrupting data, or immediately killing all those processes that used to be runnin

It's been "corrupting data" for 20 years now. What's worse: the 21st year of corrupting data, or immediately killing all those processes that used to be running fine yesterday? Or to put it another way: Let's say it takes one year to straighten out all those cases. What should happen during that year? Linus' option is that the kernel keeps running like it has been running the last 20 years. Linus is against the option that all those cases crash straight away. What you wrote about your code is that you can make sure to avoid those bugs in the first place, by putting in bounds checks. But that's not the position Linus is in. Linus has to deal with the past 20 years of lack of such checks.

geofft 9y ago
That would make sense if the kernel is static, but it's not. New code is going in, and new applications are using the kernel, and new people are using the kernel constantly. New attackers with new techniques are showing up every day, too. And the new code in the kernel is likely introducing new bugs. I understand Linus' position about userspace backwards compatibility. I don't think anyone actually takes advantage of it in practice to the extent he seems to believe. That's why Red Hat maintains extremely long-term forks of the kernel from an ancient stable release, and even distros that do not make or lose money on compatibility (e.g. Debian) don't update kernel versions in stable releases. I've worked at what amounted to a Linux-on-the-desktop startup, and we were afraid to upgrade the kernel without upgrading a pile of userspace (udev, X, libGL, etc.) in concert - and when Ubuntu announced https://wiki.ubuntu.com/Kernel/LTSEnablementStack https://wiki.ubuntu.com/Kernel/LTSEnablementStack we were quite happy because it meant we could stop upgrading to every non-LTS Ubuntu release just to pick up hardware support. I've worked at a high-frequency trading shop that was hesitant to upgrade even point releases without significant vetting. These are both places where we hired people specifically for kernel expertise and where understanding the Linux kernel was part of our competitive advantage; it's hard for me to believe that the average company doing webdev on their Macs and running production on some random Linux AMI is more confident in kernel upgrades. So, if you have some worry that your kernel that's been serving you for the last 20 years will start crashing instead of corrupting data, there's an easy answer: stay on your stable branch, which you're probably already doing. Make your kernel static enough that the argument makes sense. I would firmly agree with an argument that new security hardening techniques do not belong in a stable branch. Go run some test traffic on the new kernel, but keep the old one in production while you do that. But I don't think anyone is served well by the advice to go ahead and take a new kernel release and trust that it won't corrupt data just because previous kernel versions haven't done so for the past 20 years. Or, for that matter, that the new kernel release won't start killing your processes. A misconfigured OOM killer is just a bug, too.

geofft 9y ago

That would make sense if the kernel is static, but it's not. New code is going in, and new applications are using the kernel, and new people are using the kernel constantly. New attackers with new techniques are showing up every day, too. And the new code in the kernel is likely introducing new bugs. I understand Linus' position about userspace backwards compatibility. I don't think anyone actually takes advantage of it in practice to the extent he seems to believe. That's why Red Hat maintains extremely long-term forks of the kernel from an ancient stable release, and even distros that do not make or lose money on compatibility (e.g. Debian) don't update kernel versions in stable releases. I've worked at what amounted to a Linux-on-the-desktop startup, and we were afraid to upgrade the kernel without upgrading a pile of userspace (udev, X, libGL, etc.) in concert - and when Ubuntu announced https://wiki.ubuntu.com/Kernel/LTSEnablementStack https://wiki.ubuntu.com/Kernel/LTSEnablementStack we were quite happy because it meant we could stop upgrading to every non-LTS Ubuntu release just to pick up hardware support. I've worked at a high-frequency trading shop that was hesitant to upgrade even point releases without significant vetting. These are both places where we hired people specifically for kernel expertise and where understanding the Linux kernel was part of our competitive advantage; it's hard for me to believe that the average company doing webdev on their Macs and running production on some random Linux AMI is more confident in kernel upgrades. So, if you have some worry that your kernel that's been serving you for the last 20 years will start crashing instead of corrupting data, there's an easy answer: stay on your stable branch, which you're probably already doing. Make your kernel static enough that the argument makes sense. I would firmly agree with an argument that new security hardening techniques do not belong in a stable branch. Go run some test traffic on the new kernel, but keep the old one in production while you do that. But I don't think anyone is served well by the advice to go ahead and take a new kernel release and trust that it won't corrupt data just because previous kernel versions haven't done so for the past 20 years. Or, for that matter, that the new kernel release won't start killing your processes. A misconfigured OOM killer is just a bug, too.