Patching the Linux kernel till the cows come home
A little while ago I made a post about RHEL and all those patches to their kernels. Since that post I started thinking about the patches, and started to experiment with the theory of back-porting.
I currently maintain a list of Linux CVE issues and this is where my experiment begun. If you really think about it - that isn’t a whole lot. Sure these are security specific issues, but I know for a fact that this isn’t a complete list of patches to security issues. But just security fixes asside - exactly how many patches that go into later versions could also apply to old ones?
Turns out, a lot. I mean a LOT. “Holy patches batman!” as Tim might say. About 40% of the 2.6.25 tree (including all patches except ones from release candidate 1) apply cleanly to the 2.6.24.7 kernel. A few reference data structures or functions that don’t exist in 2.6.24.7, and thus cause build errors, so those are removed during the build process. No interfaces change (because the bulk of those happen in the release canidate 1’s, which have thousands of patches in themselves, any anything after that is likely to fail to apply).
Anyway, that’s about 1400 patches! Regression tests with the Linux Test Project after it’s built show no problems. I’ve been running it since I first built it - haven’t seen any issues. Who knows how many potential security problems I just fixed?
So, I updated my grsecurity RPM yum repo 2.6.24.7 branch of the grsecurity kernel with these 1400 some odd patches. When the 2.6.26 linux kernel is released as stable, I’ll have a few thousand more to review. Luckily I have the bulk of it scripted.
I’m sure there are some patches that could still apply to the older kernel with a few tweaks - but I currently don’t have to resources to review each one of the 2100 patches manually for this purpose. I’m also quite certain that this kernel won’t build on arches other then x86 - but all you’d have to do to get it to build is determine which patch caused the build error, which is very easy to do, and reverse it. When I get a 64bit machine to play with, I’ll build the kernels for x86_64. Same goes for other arches - testing will happen when I have the hardware available.
And for version control - since this is the linux kernel we’re talking about - I’m using git. Here is the git repository for this project.