Enhancing Asymmetric Process Migration

In the before-time, clustering identical CPUs was a big deal. Nowadays, symmetric multiprocessing (SMP) systems are the standard for general-purpose computers. The new weirdness involves asymmetric multiprocessing (AMP). It seems like all the latest person-enhancers want to have certain CPUs for the hard work and certain CPUs for the so-so work.

How does the kernel decide which process to migrate to which CPU when there could be any number of variables to consider? Dietmar Eggemann and Quentin Perret have been working on this issue, along with massive numbers of other developers across the gadget-making industry. They posted a patch recently, targeting systems with energy-efficient CPUs running alongside less efficient hardware. They wanted the system to load up the energy-efficient CPUs with as many processes as possible, before resorting to the less efficient CPUs.

The problem with their code, as they readily acknowledged, was that in order to identify the best available CPU that wasn't already at maximum load, the patch would run through a brute-force algorithm that would only really be efficient on systems with a relatively small number of CPUs. As Dietmar put it, "This patch is an attempt to do something useful, as writing a fast heuristic that performs reasonably well on a broad spectrum of architectures isn't an easy task."

There's definitely some justification for this approach. A lot of gadgets on the market only have a small number of CPUs, so there's a fair chance that a lot of hardware would benefit from this patch. On the other hand, there are various kernel gatekeepers, including Linus Torvalds, who prefer to get patches that solve a whole problem in the most natural way, rather than doing something that's good enough for some users, but misses the main point. So although there was no major objection to this patch, it's likely that someone will have something to say before it makes it into the kernel.

Protecting Users' System Control

Security is sometimes in the eye of the beholder. To the user, a secure system is one that they control themselves. To various vendors, on the other hand, a secure system is one in which the user cannot override the will of the vendor.

This dates back to the early days of "Trusted Computing" and beyond. The argument is that if the vendor can control the entire software chain, they can leverage all sorts of things like proprietary video and audio content, unblockable ads, microcharges for time spent on particular activities, and so on. All of these things become possible, if only you can prevent the user from altering the system.

This was what software companies were trying to do in the 1980s, before Linux came along – force users into a position where they could only use that particular company's offerings. Countering this was not the only motivation behind the arrival of GNU, Linux, and other free software, but it was a big factor.

It's a war that neither side has won. Linux keeps trying to give users control over their systems, and proprietary corporations keep trying to take that control for themselves. Things like the Linux-based Android operating system, with app stores full of closed-source Android apps, are a continuation of that debate.

Recently, David Howells submitted a patch to implement "lockdown," a feature designed "to protect against unauthorized modification of the kernel image." As written, it would operate in conjunction with UEFI Secure Boot, which prevents "unauthorized" operating systems from loading onto a given machine. Matthew Garrett proved to be the patch's biggest exponent, posting many times in its defense.

However, Linus Torvalds, joined by Andy Lutomirski and others, was less interested in the patch's potential benefits and more interested in the ways it might be abused by vendors, to wrest control of a given system away from the user and keep it in the hands of the vendor alone.

A big element of the debate involved accusations by Linus that Matthew was unwilling to admit the true purpose of the patch and kept skirting the real issue in his technical responses.

One of Matthew's clearer defenses of the patch was that the whole point of Secure Boot was to prevent unauthorized kernels from loading into the system. And the point of lockdown was to prevent the running system from being modified. Without lockdown, a user could easily bypass Secure Boot by simply loading a signed kernel that would in turn load any kernel the user desired. If the user could do that, Matthew said, then there would be no value to Secure Boot, because the user could just load whatever kernel they wanted. This kind of one-kernel-loading-another action is called "chainloading."

Another element of Matthew's defense of the patch was that if users didn't like the feature, they could simply disable it in their kernel. They could use a kernel that simply didn't include those security features.

But Linus and Andy, as well as Al Viro, felt that this was a disingenuous argument. As Al put it, this made the assumption that the user had the ability to turn off Secure Boot. If the manufacturer includes firmware that enforces Secure Boot, then Secure Boot itself becomes "a misfeature that has to be worked around. Making that harder might improve the value of [Secure Boot] to said manufacturers, but what's the benefit for everybody else?"

And in a similar vein, Linus said to Matthew, "I may want to know that I'm running my kernel, but once that is the case, I trust it. In fact, I tend to trust it more than some random vendor key. You should too." He also added, "secure boot can be hard to turn off. Sometimes 'turn off' means 'you just have to add your own keys'. Yes, on x86 hardware at least at some point MS actually had the rule that it has to be something you can turn off. That rule is apparently not true on ARM, though."

Matthew never gave an inch in the debate – he never affirmed that the goal of the patch was to lock users out of controlling their systems. Ultimately the patch was not accepted. But the whole discussion shows that even today, there is a significant effort to "secure" systems against their proper users.