A relatively tiny code change by penguin premier Linus Torvalds is making a measurable improvement to Linux's multithreaded performance.

The code commit has the catchy name of x86/uaccess: Avoid barrier_nospec() in 64-bit copy_from_user() and it's a security tweak intended to counter the types of security holes known as Meltdown flaws and Spectre attacks when they became public in 2018. Unfortunately, these problems haven't gone away. As The Register covered just last month, this type of attack remains current.

The patch is a rewrite of one originally submitted by Red Hat developer Josh Poimboeuf, which Torvalds revised to make faster. "The kernel test robot reports a 2.6 percent improvement in the per_thread_ops benchmark," he wrote in the commit.

Torvalds's version avoids using the barrier_nospec() API, which prevents speculative execution of some machine code. Speculative execution is a feature of modern CPUs that use branch prediction to try to predict what program code will be run before it's needed, so it can be run and the results cached in advance. If the prediction is correct, it saves time; if it isn't, the results are discarded. The snag is that this opens up a particular form of security issue, which boffins have been working on ever since.

Instead, where the copy_from_user() call wouldn't be allowed because of an invalid address, it uses pointer masking to return an address of all s.

Defending against these sorts of attacks is a necessary evil. Running web servers and the like is a primary usage of Linux, and such boxes must be locked down against every conceivable attack - even at the cost of disabling performance-enhancing features. It makes servers safer but slower. Torvalds is known for disapproving of such performance-killing measures (to put it mildly).

(On a standalone local machine such as a desktop or laptop, which doesn't allow inbound connections, you can turn this stuff off and enjoy better performance in relative safety - if you know what you're doing and accept the small but potential risk.)

It's not a big deal, but it shows why the kernel commandant still commands over a million a year from the Linux Foundation. Very few people indeed have his level of technical knowledge, especially of the x86 architecture - and of those who do, most of them work for big chip vendors. They're under NDA and can't talk about it. That's why, before the Linux Foundation, chip vendor Transmeta hired him. It got the company the low-level expert knowledge they needed to build their Crusoe VLIW chips, which ran x86-32 code by emulating it. ®