Thanks Linus. Torvalds patch improves Linux performance by 2.6%
- Reference: 1730914327
- News link: https://www.theregister.co.uk/2024/11/06/torvalds_patch_linux_performance/
- Source link:
The code commit has the catchy name of [1]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 [2]Meltdown flaws and [3]Spectre attacks when they became public in 2018. Unfortunately, these problems haven't gone away. As The Register [4]covered just last month , this type of attack remains current.
The patch is a rewrite of one originally submitted by Red Hat developer [5]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.
[6]
Torvalds's version avoids using the [7]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 [8]boffins have been working on ever since.
[9]
Instead, where the [10]copy_from_user() call wouldn't be allowed because of an invalid address, it uses pointer masking to return an address of all 1 s.
[11]Combustion engines grind Linus Torvalds' gears
[12]Linus Torvalds: 90% of AI marketing is hype
[13]Linus Torvalds affirms expulsion of Russian maintainers
[14]Linus Torvalds declares war on the passive voice
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 [15]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 [16]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 [17]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, [18]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. ®
Get our [19]Tech Resources
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0fc810ae3ae110f9e2fcccce80fc8c8d62f97907
[2] https://www.theregister.com/2018/02/12/meltdown_kpti_performance_analysis/
[3] https://www.theregister.com/2018/11/20/linux_kernel_spectre_v2_patch_slowdown_intel/
[4] https://www.theregister.com/2024/10/18/spectre_problems_continue_amd_intel/
[5] https://github.com/jpoimboe
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zyv1FlPLBgOPLAjC-o7QrgAAAEw&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[7] https://docs.nxp.com/bundle/GUID-805CC0EA-4001-47AD-86CD-4F340751F6B7/page/GUID-C66472A3-F9A8-48C8-990D-2D9ED1AD1A56.html
[8] https://www.theregister.com/2018/06/16/speculative_execution_spectre_meltdown/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zyv1FlPLBgOPLAjC-o7QrgAAAEw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://www.cs.bham.ac.uk/~exr/lectures/opsys/14_15/docs/kernelAPI/r4081.html
[11] https://www.theregister.com/2024/10/30/linus_torvalds_ev/
[12] https://www.theregister.com/2024/10/29/linus_torvalds_ai_hype/
[13] https://www.theregister.com/2024/10/23/linus_torvalds_affirms_expulsion_of/
[14] https://www.theregister.com/2024/10/08/linus_torvalds_grammar_complaint/
[15] https://www.theregister.com/2018/01/22/intel_spectre_fix_linux/
[16] https://www.theregister.com/2022/07/18/improve_linux_performance/
[17] https://projects.propublica.org/nonprofits/organizations/460503801
[18] https://www.theregister.com/1998/09/28/update_transmeta_transmogrified_by_linux/
[19] https://whitepapers.theregister.com/
Re: Don't disable that on the client machine!
That's generally not how these attacks work. It's extremely difficult to pull off these attacks running some dodgy script due to the extremely precise timings required and how little data can be lifted.
However if you are running shared services, then the bad actor can install the software in their instance, and just sit the collecting the data over days, weeks, months.
"why the kernel commandant"
So, who's Destro?
Joking aside, this is a significant improvement and shows that (sometimes) "Peephole optimisation" is worth doing. Not often, but sometimes.
Re: "why the kernel commandant"
"even at the cost of disabling performance-enhancing features."
If they wrote lightweight HTML instead of heavy code for gathering personal data we wouldn't need performance enhancement.
Re: "why the kernel commandant"
The HTML in question isn't the issue here. The server is delivering a file for HTML, and one or more files for js, css etc that is all highly compressible text. One image is usually more payload than all the HTML, CSS and JS combined.
Malicious exploits can target the server, others can target a client. Each have differing mitigations.
Servers can operate in read-only for system mounts to reduce risk, as well as process isolation and containerization. The ladder techniques can also be used in a client browser. For Linux clients, this means appimage/flatpak/snap. Windows and Mac have different but similar approaches for browser isolation.
None of this has anything to do with the complexity of a given website.
«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. »
Transmeta also ran AMD64. Actually, AMD hired them to simulate the architecture before the actual silicon was ready, for the benefit of SW/OS developers
https://www.theregister.com/2000/11/07/transmeta_helping_out_amd_ms/
It shows indeed
It shows why Linus Torvalds is still the top programmer in existence.
All hail the Torvald !
Fractional Gains
Considering that the efficiency improvement still allows (some) speculative code execution, this is pretty much as good as we could have expected. What pleases me the most, is that this sort of strategy may be more generally applied to a number of potential security bottlenecks. Also, the nimbleness with which Linux distros can code in unique solutions to these issues, makes it more and more valuable as time goes on. Once again, a carefully curated hive mind shows itself superior to proprietary authoritarianism. There is a general lesson here, methinks.
Transmeta! That takes me back... the front page of liliputing.com used to be full of Crusoe and Efficeon vapourware, including the OQO palmtop and one of the OG netbooks, the Dialogue Flybook. Without hiring all their famous names, no way their terrible chipset would have gotten inside as many machines as it ended up in.
Marginal gains
Worked in a nanotechnology group where one of the PhD rocket scientists proudly announced: "I've sped up the analysis code by 10%. It's going to finish a day early!".
Don't disable that on the client machine!
> 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 actually the other way around. Web server machine runs only code that is installed on it, hopefully from a trustworthy repository, and leaking secrets from one process to another is not a threat.
On the client machine, you use browser that runs (javascript/wasm) code downloaded from someone's server that may not be trustworthy. And can steal your secrets.
(The same way, it is a threat for a provider who runs other people's vms/containers that run untrusted code.)