Zack's Kernel News
Zack's Kernel News

Zack discusses removing dead ports, new minimum GCC version jumping from 3.2 to 4.8, Intel considering hardware changes to mitigate security flaws, enhancing asymmetric process migration, and protecting user's system control.
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.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
Zorin OS 17 Beta Available for Testing
The upcoming version of Zorin OS includes plenty of improvements to take your PC to a whole new level of user-friendliness.
-
Red Hat Migrates RHEL from Xorg to Wayland
If you've been wondering when Xorg will finally be a thing of the past, wonder no more, as Red Hat has made it clear.
-
PipeWire 1.0 Officially Released
PipeWire was created to take the place of the oft-troubled PulseAudio and has finally reached the 1.0 status as a major update with plenty of improvements and the usual bug fixes.
-
Rocky Linux 9.3 Available for Download
The latest version of the RHEL alternative is now available and brings back cloud and container images for ppc64le along with plenty of new features and fixes.
-
Ubuntu Budgie Shifts How to Tackle Wayland
Ubuntu Budgie has yet to make the switch to Wayland but with a change in approaches, they're finally on track to making it happen.
-
TUXEDO's New Ultraportable Linux Workstation Released
The TUXEDO Pulse 14 blends portability with power, thanks to the AMD Ryzen 7 7840HS CPU.
-
AlmaLinux Will No Longer Be "Just Another RHEL Clone"
With the release of AlmaLinux 9.3, the distribution will be built entirely from upstream sources.
-
elementary OS 8 Has a Big Surprise in Store
When elementary OS 8 finally arrives, it will not only be based on Ubuntu 24.04 but it will also default to Wayland for better performance and security.
-
OpenELA Releases Enterprise Linux Source Code
With Red Hat restricting the source for RHEL, it was only a matter of time before those who depended on that source struck out on their own.
-
StripedFly Malware Hiding in Plain Sight as a Cryptocurrency Miner
A rather deceptive piece of malware has infected 1 million Windows and Linux hosts since 2017.