Thanks, Linus. Torvalds patch improves Linux performance by 2.6% 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 …
> 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.)
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.
Speculation attacks aim to extract just one small bit of data, a key or password. They're not trying to read your email.
Initial comment is correct. The question is whether you have a trust boundary on your system, and webservers basically don't.
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.
Even so, there are spectre attacks in JavaScript and WASM (2nd paragraph on P2).
The difficulty doesn't derive from any real technical limit. It's difficult because you've got an extra language layer to work through. You need to find wasm/script sequences that cause a browser to execute the desired memory pattern. Those surely exist (and they're NOT browser bugs) but they're not immediately documented ready for use in the same way a memory manipulation is in a simple bit of C code. Your exploit will be more bespoke because it's tied to a particular browser and maybe host OS. And you have to roll your own timing solution because browsers disabled high-resolution timing. These are problems that are eminently solvable to achieve an exploit just as robust as a bare-metal one, just much more time-consuming to to work through it all.
Once good exploit engines are out there, browser developers will be locked in a more intense arms-race to thwart them. It'll be a losing battle because browser scripting is too powerful and they'll be begging us to turn back on our desktop spectre mitigations. I don't recommend turning them off.
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/
He isn't.
It's probably not helpful to idolise him like that.
Don't get me wrong, he's no slouch.
I, and most people here, would be scrabbling around in his dust going 'We are not worthy', but 'the top programmer in existence.', nah.
He's a clever man who developed a unix-alike kernel, and has done a bang up job of stewarding it since then. However, like any great in their field he was also 'right place, right time' too. (Had BSD not been mired in legal issues, or Hurd been ready1 for example).
He's also disproportionally idolised, as many top people in their field are.
I'm not saying this to diminish 'The Torvald', but there are other clever programmers out there, many who've contributed as much, or more, to the development of computer science as a field as Linus has.
1 Lol.
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.
no way their terrible chipset would have gotten inside as many machines as it ended up in.
Transmeta floundered because Intel simply appropriated their technologies, allowing them to jump ahead in energy efficiency:
https://www.computerworld.com/article/1565866/intel-settles-patent-case-with-transmeta-for-250m.html
might have been wasted here as it might have been better used for one of Linus' periodic rants.
The man with a shifter aka attitude adjuster which suitably applied might result in performance gains for the kernel if not from the adjustee.
All modern processors are affected by Spectre flaws:
"Spectre has been shown to work on Intel, AMD, ARM-based, and IBM processors."
It's a question of superscalar pipelined processors. Not RISC vs CISC. x86 CPUs are RISC behind the scenes, anyhow.
All modern processors have those traits, or else they'd perform terribly.
it's a 2.6% increase when running the per_thread_ops benchmark. Unforch this story has blown up so searching for that benchmark gets loads of news sites parrotting this press release/figure.
What is the real world implication of this? Sounds like each thread can now run 2.6% more ops in a given period, is that genuinely what it means?
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
