Removing Dead Ports

When no one's using a particular piece of hardware, Linus Torvalds becomes very likely to accept a patch removing that hardware from the kernel. It's a similar reason for why he doesn't want to add security patches that don't actually fix security holes, but that just make it "harder" for attackers to design worms. He wants to support hardware that people actually use and fix bugs that actually exist, but he doesn't want to add features that no one will use or that add bloat without actually adding a feature.

Some hardware ports came onto the chopping block recently for this reason. Arnd Bergmann posted a patch to remove Blackfin, CRIS, FRV, M32R, Metag, MN10300, Score, and Tile. He also gave his opinion on why these particular pieces of hardware had disappeared from use. Apparently, as he put it, "while the eight architectures are extremely different, they all suffered the same fate: There was one company in charge of an SoC line, a CPU microarchitecture and a software ecosystem, which was more costly than licensing newer off-the-shelf CPU cores from a third party."

The moral of that story seems to be: Companies shouldn't make custom hardware when generic will do just as well. It's sort of the same reason companies should use Linux instead of writing their own operating system whose key features would soon be incorporated into Linux anyway and be better maintained as well. But apparently this lesson must be learned over and over again.

An interesting aspect of this particular purge was the idea of how best to make it easy for future developers to resurrect those architectures in Linux if they wished. Even when clearing out old and unused parts of the kernel, Linus wants to leave the door open to bring them back if necessary. For that reason, he wanted each architecture to be removed in its own separate patch.

In reality though, as was pointed out in the mailing list discussion, it'd be virtually impossible to resurrect any of these ports by simply reverting the patch that took them out. Geert Uytterhoeven explained that with the kernel itself constantly advancing, anyone trying to bring back one of those ports would probably want to use the newer, more modern features, rather than do a simple patch reversion.

Pavel Machek said it would be more realistic to revert a given patch and then do incremental improvements, in order to get to the place Geert was talking about. Implementing an entire port from scratch, he felt, would not be realistic. Although as Arnd put it, the kernel was developing in ways that would ultimately be incompatible with a pure revert, and very soon a reversion simply wouldn't be possible. And he also added that some of these ports had become so outdated that the kernel probably hadn't been able to run on them for a long time.

The discussion ended, and the patches are certainly going to be accepted. The thing I like about this debate is the attention given to future developers who might care about these architectures that are all but dead. There really is a tremendous focus on ensuring that Linux runs on every piece of hardware that anyone might actually use. And there really is an equally fine attention given to keeping the kernel free of dead architectures and of dead code in general.

New Minimum GCC Version Jumping from 3.2 to 4.8

For many years, GCC v3.2 has been the official minimum. This means that version 3.2, and any later GCC version (with a couple of special exceptions), was officially supported to compile the Linux kernel successfully. Supporting such an ancient minimum is desirable because the kernel people don't want to make assumptions about what software is running on user systems. They want anyone to be able to compile a working kernel, using pretty much whatever versions of the tools that are available.

The problem with this is that it isn't true. The topic recently came up on the mailing list, and at one point Linus Torvalds said, "our documentation may claim that gcc-3.2 is the minimum supported version, but Arnd pointed out a few months ago that apparently nothing older than 4.1 has actually worked for a longish while, and gcc-4.3 was needed on several architectures."

The question at that point became what version to list as the new official minimum. Clearly it should include as many actively maintained Linux systems as possible. But in order to maximize the ease of kernel maintenance, it should also be the highest GCC version that the Linux developers could get away with. After all, newer GCC versions support programming constructs that are much better than older versions. Having to support those older GCC versions means having to maintain whole branches of ugly kernel code that exist solely for those older GCC versions.

Step by step, the kernel developers walked up the GCC versions, trying to eliminate them from consideration. With 4.3 needed on several architectures, it was a natural starting point. Over the course of discussion, it came out that GCC 4.4 had certain breakage that, although it didn't seem to hit anyone using a regular Linux distribution, was worth taking note of. It was also significant that GCC's asm goto feature had first appeared in version 4.5 and allowed the kernel to use much cleaner code than earlier versions. Bumping the official GCC minimum to 4.5 would therefore allow the kernel folks to rip out a lot of ugly code that currently had to exist alongside more recent asm goto code. Linus in particular was in favor of doing that. So for awhile, it looked like GCC 4.5 would be the new minimum.

However, Arnd Bergmann pointed out that GCC 4.5 was not able to build kernels for some of the newer ARM systems. In tests he'd done last year, he'd identified GCC 4.6 as a better candidate for the official minimum, for that reason.

But then the question became: Were any Linux distributions – especially the older releases that were in "long-term maintenance mode" – actually using GCC 4.6? Or were they using something more recent? If they were using anything more recent, Linus reasoned, then the official GCC minimum might as well be bumped up to that.

Arnd took a look and found that some of those long-term distributions were using GCC versions older than 4.6, which meant they were not relevant to the question, since Linus was already committed to bumping the GCC minimum up to at least 4.6, and the rest of those distributions were either about to reach their end of life or used GCC 4.8.

Presto! GCC 4.8 would become the new official minimum: new enough to let the kernel use the asm goto programming construction, and old enough to cover every Linux distribution still in use. As a result of this decision, it's likely that large swaths of code will be considered dead and will be gutted out of the kernel tree.

Intel Considering Hardware Changes to Mitigate Security Flaws

Folks from Intel are collaborating with the Linux kernel developers to find good ways to fix or work around the Spectre, Meltdown, and other hardware flaws that have been discovered in their chips. Recently, Dave Hansen from Intel asked if a particular hardware change seemed useful to the Linux folks. Specifically, he said, Intel was considering adding a new bit to the IA32_ARCH_CAPABILITIES register, to tell when the return stack buffer (RSB) was empty. Normally, the RSB would receive data in a stack and pop it off when requested. But if the stack ever emptied out, it became vulnerable to a Spectre attack. The new bit would check this empty condition, so the attack could be avoided.

Linus Torvalds approved wholeheartedly, since this would let the kernel avoid having to do certain unpleasant tests. At first, there were also various possible objections to Dave's proposal, as various kernel folks analyzed any possible ways for attackers to try to work around Intel's fix. But one by one, these objections were dropped, and the change was generally approved.

Of course, Intel will also be weighing many other considerations before making these sorts of feature changes to their hardware, but it's excellent to see this sort of open collaboration happening.