Linus Torvalds Growing Frustrated By Buggy Hardware, Theoretical CPU Attacks (phoronix.com) 73
jd writes: Linus Torvalds is not a happy camper and is condemning hardware vendors for poor security and the plethora of actual and theoretical attacks, especially as some of the new features being added impact the workarounds. These workarounds are now getting very expensive, CPU-wise.
TFA quotes Linus Torvalds:
"Honestly, I'm pretty damn fed up with buggy hardware and completely theoretical attacks that have never actually shown themselves to be used in practice.
"So I think this time we push back on the hardware people and tell them it's *THEIR* damn problem, and if they can't even be bothered to say yay-or-nay, we just sit tight.
Because dammit, let's put the onus on where the blame lies, and not just take any random shit from bad hardware and say 'oh, but it *might* be a problem.'"
TFA quotes Linus Torvalds:
"Honestly, I'm pretty damn fed up with buggy hardware and completely theoretical attacks that have never actually shown themselves to be used in practice.
"So I think this time we push back on the hardware people and tell them it's *THEIR* damn problem, and if they can't even be bothered to say yay-or-nay, we just sit tight.
Because dammit, let's put the onus on where the blame lies, and not just take any random shit from bad hardware and say 'oh, but it *might* be a problem.'"
Easy to say, but not practically fixable... (Score:2)
It's easy (and true) to say it is the fault of the hardware vendors.
However, once the product ships, it's unfixable. The only solution is a software fix.
And theoretical attacks are acknowledged vulnerabilities. They only remain theoretical until some hacker needs it to bypass or access data and they implement it. Maybe we'll know about that transition, maybe we won't.
Re:Easy to say, but not practically fixable... (Score:4, Informative)
Re: (Score:2)
that way lies madness; the most popular cpu will be the most studied for vulnerabilities
you may as well decide to let the market decide and then...choose the second or third most popular platform
Re: (Score:2)
Properly secure hardware is too slow? (Score:1)
Consider for a moment that the "work-arounds" are reducing the CPU to the performance level of a properly "Secure" CPU. How then can we really properly assess the CPU cost of these work-arounds, if it isn't as simple as measuring the time to co
Re: (Score:2)
It isnt the cheaters that incentivize insecurity for performance, its the market of people saying "take my money please" that incentivize it.
Whats wrong with that?
Lets get this down to brass tacks. Whats your beef with those people and why would you interfere in their market? Are you levitating above them in judgement?
Re: (Score:2)
The most commonly stolen car was the Civic. It wasn't the most stolen because it was the most vulnerable, but because it had the largest market for underground resale of vehicles or parts. Similarly, is Linux less vulnerable to malware than Windows, or is Windows just the biggest target because it's by far the most common OS to attack?
Now in some ways, I think x86_64 architectures have a big problem in that they are so extremely complex with such long architectural lives. A CISC processor adapted to do s
Re: Easy to say, but not practically fixable... (Score:3)
"Similarly, is Linux less vulnerable to malware than Windows, or is Windows just the biggest target because it's by far the most common OS to attack?"
That's what biggest target means
You asked if A was A.
Linux is the most valuable OS to attack, Windows is easiest.
Re: (Score:2)
Yeah fuck me for buying from the only two x64 vendors.
There's always IBM POWER. https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
You also have a few ARM desktop and server processors to choose from now, but it's only a matter of time that they find security vulnerabilities in those.
Re: (Score:2)
Yeah fuck me for buying from the only two x64 vendors.
There's always IBM POWER. https://en.wikipedia.org/wiki/... [wikipedia.org]
I love IBM POWER! I own 2 POWER9 systems from https://raptorcs.com/ [raptorcs.com]. A Talos II based system and a Blackbird based system. I also intend to buy one of their new systems in 2025 if I can scrounge up the money.
However, at least POWER9 is vulnerable to meltdown (and I think aarch64 is as well). So far as far as speculative execution vulnerabilities go everything is vulnerable except like Itanium.
Maybe with AI guided compilers VLIW could actually be viable.
Re: (Score:2)
So the program might run and do what its supposed to do this compile? Maybe not?
Yeah lets not do that.
How about an AI-guided ISA and architecture design instead? It would most certainly be something where memory isnt flat at all, making it quite different from current systems and will probably demand well matured programming language support.
Re: (Score:2)
AI-guided compilers? So the program might run and do what its supposed to do this compile? Maybe not? Yeah lets not do that. How about an AI-guided ISA and architecture design instead? It would most certainly be something where memory isnt flat at all, making it quite different from current systems and will probably demand well matured programming language support.
I'm not suggesting anything remotely like that.
With VLIW, parallelism isn't abstracted by the CPU (you get to deal with parallelism directly in the ISA) as speculative execution is moved to the compiler. Unsurprisingly, compilers were never very good at this... But apparently you could get good performance out of Itanium with hand-tuned assembly, which isn't really practical to expect all software to have such optimizations (especially since need to recompile your software for newer VLIW CPU iterations m
Re: (Score:1)
apart from being at the bottom of the ocean, why is the Itanic immune to speculative execution vulnerabilities?
Re: (Score:2)
Intel wanted the compiler to do all the magic instead.
Re: (Score:2)
apart from being at the bottom of the ocean, why is the Itanic immune to speculative execution vulnerabilities?
With VLIW, the speculative execution is supposed to be done by the compiler. The parallelism is built directly into the instruction set rather than obscured by the CPU and then determined at runtime.
Reading about VLIW it's quick to see that this is one of those ideas that must've sounded great in academia, but wouldn't pan out in the real world (at least for general purpose CPU's).
Intel kept saying Itanium will perform, we just need better compilers! But this never really panned out which isn't at all
Re: Easy to say, but not practically fixable... (Score:2)
Right but Torvalds point is still important even if the work still has to be done. Are there changes the hardware vendors could make to do a better job of catching some of these things up front? Do they need to reconsider some aspects of their architecture with the security first mindset? If it's purely theoretical does the code get written but not implemented until it's needed? Because it's also true that if we have to implement software fixes that in some cripple the hardware after release you're not real
Re:Easy to say, but not practically fixable... (Score:5, Informative)
It's easy (and true) to say it is the fault of the hardware vendors.
However, once the product ships, it's unfixable. The only solution is a software fix.
There's another level between hardware and OS: microcode updates shipped by the CPU manufacturers including both Intel and AMD.
These are loaded into CPUs at boot to patch problems found after manufacturing. Fixes made entirely in microcode don't require OS changes.
Re: (Score:1)
Re: (Score:3)
In some cases, yes, but many hardware issues can also be patched around through microcode/firmware updates.
The issue is more how much time/effort you want to spend hardening yourself against theoretical problems. Until something can be demonstrated practically, I certainly wouldn't be spending much time on it. This has always been a point of tension between security researchers and kernel/SW developers, long before HW-based attack vectors started to become more common.
Re: (Score:2)
The issue is more how much time/effort you want to spend hardening yourself against theoretical problems. Until something can be demonstrated practically, I certainly wouldn't be spending much time on it.
Meanwhile, a three-letter agency near you, as well as its counterparts in other countries are adding new stuff in their big stash of zero-days. And you keep your high performance toys. A win-win situation.
Re: (Score:3)
True, but AMD and Intel firing large numbers of QA staff from their chip lines and trying to accelerate development to stay ahead of the game isn't helping matters.
This was a gamble that was always doomed to lead to spectacular crashes, it was merely a case of how many and when.
Re: (Score:2)
Yes. But I think the hardware vendors should provide developer resources here to mitigate the problem they created.
Theoretical attacks don't always matter (Score:2)
Re: Easy to say, but not practically fixable... (Score:1)
Re: (Score:2)
"The only solution is a software fix."
Any (competent) processor design is going to include lots of defeature bits.
New architectural features aren't added in steppings. The first version is there from the beginning and they are publicly enabled once validated.
Security only weakens over time. (Score:5, Interesting)
I'm pretty sure the cache timing side channel attacks were a theoretical curiosity, until suddenly, very suddenly they weren't and someone demonstrated grabbing private keys between isolated VMs running on one machine.
The trouble with theoretical attacks is you never know when they become non theoretical but they can turn into very nasty 0-days very quickly when they do.
Re: (Score:3)
The thing to watch for is that sometimes the set-up to demonstrate the exploit is so specific and so designed to be exploitable that it becomes the moral equivalent of placing a plate of cookies in a kindergarten, loudly announcing "Gee, I hope nobody eats these delicious cookies when I leave the room for half an hour!", then announcing that the "hungry kiddee" attack is a threat level 25 out of 10 and claim that it would be irresponsible not to lock all cookies in a vault with at least a 10 disc lock.
Re: Security only weakens over time. (Score:2)
Re: (Score:2)
Well, it was announced decades ago. I don't think anyone took it seriously, but it was known.
Re: (Score:2)
Well, it was announced decades ago. I don't think anyone took it seriously, but it was known.
Basic cache timing attacks were announced decades ago, and have long been taken seriously for security-sensitive computation, especially cryptography. But the new generation of attacks based on speculative execution are new. Well, as of 2018, when Spectre and Meltdown were announced. Many others have been found since then, but those were the first. https://en.wikipedia.org/wiki/... [wikipedia.org] has a good summary.
Re: (Score:2)
And there are some very obscure attacks that can be made. A well designed processor, by 2023 standards, may have a very insecure design as soon as a new attack is discovered. Ie, some things in the past: pay attention to how long an operation takes, how much current was used, and that gives you a slight edge in determining a branch taken vs not taken, and that gives you a step up in figuring out the decryption key or what the protected data looks like.
Perhaps a basic hardware punch list? (Score:3)
It would be interesting to see a hardware "minumum standard", perhaps. Worst case, if someone has cruddy hardware, emulate their crap, Bochs style, and then point the finger at them for having something that cannot be done in software, so the entire segment has to be emulated on a low level, just to ensure that it won't cause issues with the rest of the system.
Re: (Score:2)
It would be interesting to see a hardware "minumum standard", perhaps. Worst case, if someone has cruddy hardware, emulate their crap, Bochs style, and then point the finger at them for having something that cannot be done in software, so the entire segment has to be emulated on a low level, just to ensure that it won't cause issues with the rest of the system.
The problem is that the current generation of hardware flaws that Linux is being asked to work around are for a fairly new class of security vulnerabilities, vulnerabilities that exploit modern CPUs' branch prediction and speculative execution. We can't define a list of all of the things hardware must do, and how it must do it, to be safe from these vulnerabilities because we don't yet fully understand them. We do know that we could get rid of them all by eliminating speculative execution, but the perform
Re: (Score:2)
It would be interesting to see a hardware "minumum standard", perhaps. Worst case, if someone has cruddy hardware, emulate their crap, Bochs style, and then point the finger at them for having something that cannot be done in software, so the entire segment has to be emulated on a low level, just to ensure that it won't cause issues with the rest of the system.
The problem is that the current generation of hardware flaws that Linux is being asked to work around are for a fairly new class of security vulnerabilities, vulnerabilities that exploit modern CPUs' branch prediction and speculative execution. We can't define a list of all of the things hardware must do, and how it must do it, to be safe from these vulnerabilities because we don't yet fully understand them. We do know that we could get rid of them all by eliminating speculative execution, but the performance cost would be severe, so people are understandably reluctant to take that step.
Responding to myself; there's a little more context I should have included:
Torvalds' concern about theoretical attacks is both a valid point and highly debatable. The problem is that these vulnerabilities are identified and demonstrated in laboratory conditions that are often highly unrealistic, because the researchers' job isn't to produce a usable, practical exploit chain, it's to demonstrate that an attack is possible. So as soon as they have something solid, they publish and get a CVE assigned. Does
Re: (Score:2)
Why not both? Have mitigations avai
List of usable hardware (Score:2)
Who's going to maintain the list of buggy hardware we need to avoid?
Re: List of usable hardware (Score:3)
Re:List of usable hardware (Score:5, Insightful)
A list of zero vendors is trivial to maintain. /s
EVERY platform has bugs. Who is going to prioritize what is "critical" versus "mostly harmless"?
Re:List of usable hardware (Score:4, Insightful)
Well it's the hardware vendor's responsibility. That seems to be the context here (which is a little thin in the summary). A vendor has to take an official position on whether or not a particular mitigation is needed and then, if that slows their chip down, the slowed down performance is the real performance. The controversy appears to stem from vendors not wanting to take a clear position - they want to still claim full performance and blame the kernel developers for applying the fix overly broadly under the guise of security while the vendor stays silent. I think the upshot is that Linus is calling their BS and saying that a particular hardware vendor MUST take a position if they want their mitigation included in the kernel. Then the vendor will take the appropriate hit on either the security or the performance side of that particular hardware. They don't get to have it both ways by abusing the kernel submission process. This is why "theoretical" nature of the attack is important - if it is something that is demonstrated effective then there is no ambiguity, the vendor doesn't have a choice in the matter, the community will decide for them. But that isn't what seems to be being discussed here.
Alternatively there is the possibility of separating things into trusted or non-trusted use cases. But again, the upshot is that is something the vendors need to take more leadership in and take clear positions on for specific hardware and mitigations.
You're ruining my pet project (Score:1)
Screw you guys, I'm going home!
Drop support for buggy processors (Score:2)
Re: (Score:3, Insightful)
If you eliminate the crap machines, what is left? You've pretty much removed all of the available cpus, motherboards, pre-built system, most custom rigs, ...
Re: Drop support for buggy processors (Score:2)
Re: Drop support for buggy processors (Score:1)
Linux (Score:3)
So Linux is perfect and free from bugs or theoretical attacks and will never need to be updated ever again?
Linus has always had a poor outlook on systems security, its been a constant struggle for a very VERY long time to get him to understand the implications of various attacks, even against the Linux kernel itself. This is nothing new. But now he wants his lax attitude to be more pervasive in other parts of the system too.
Re: (Score:2)
Re: (Score:2)
Torvalds has had countless issues with security. I wasn't even referencing THAT particular discussion. More recently, he was complaining about random number generation and not caring much about it, calling it a BS change, once again trivializing security.
Re: (Score:2)
How about (Score:2)
"So I think this time we push back on the hardware people and tell them it's *THEIR* damn problem, and if they can't even be bothered to say yay-or-nay, we just sit tight.
How about getting back to our roots ? If your hardware product does not use fully open firmware, we will ban it from being used on Linux. Right now, this is happening because Linux Foundation is owned by Fortune 500 Companies. So we get what we deserve by allowing this to happen.
Re: (Score:2)
Unfortunately (or not?), the days of Linux being maintained and controlled by pure-minded volunteers are long gone. Trying to shift back to that a) is not practical; and b) would likely result in a buggier, more vulnerable ecosystem.
If you want highly-skilled devs, you likely need to pay them - and pay them well. How many stories have we seen on Slashdot about FOSS projects languishing specifically because they *didn't* have financial support?
Re: How about (Score:2)
Re: (Score:2)
```
How about getting back to our roots ? If your hardware product does not use fully open firmware, we will ban it from being used on Linux.
```
Linux started on i386 with IBMPC BIOS.
What roots are we talking about?
You're going to disable everything but RISC-V and Power on an open source kernel?
Please lay out your strategy.
Re: (Score:2)
I don't know about RISC-V, but POWER CPUs have speculative execution and are vulnerable to the class of Spectre/Meltdown attacks. IBM has published mitigations on their website, with the warning that they may hurt performance. The IBM z mainframes are vulnerable too, so even big iron isn't a refuge.
Some ARM models don't have speculative execution and should be immune, but they are low-performance models. Old Intel Atoms are immune too, as well as Itanics.
Re: (Score:2)
Than niche is already filled up by RMS and his friends.
Yes and no. (Score:3)
I greatly prefer the software workaround unless the hardware solution can be proven to have zero performance impact. That results in the best outcome for everyone. Those people who have high security requirements can enable it, and those people who don't, don't have to.
I get it it's annoying to maintain, if anything the onus is on the hardware manufacturers to support the development of the software, but having in software makes it customisable
huh (Score:2)
Dude complains a lot doesn't he
Re: (Score:3)
He speaks plainly about the problem that hardware vendors do not take responsibility for bugs in the hardware. It's a very real problem with very real consequences, and one of those consequences is unfair blame placed on Linux, and its chief maintainer.
If you don't want to read his legitimate complaints, affect change in how the hardware vendors handle the situation. Or just don't read it.
Re: (Score:2)
Maybe this year will the Year of Linux on the Desktop.
Re: (Score:2)
Kernels on desktops, now there's a notion.
Re: (Score:2)
The world is nasty and there is a lot to complain about.
Always been bugged (Score:2)
x86 hardware has had speculative execution vulnerabilities built into it since the Pentium. There's nothing new here. He should probably be glad that at least one company has fixed their problems in hardware.
Re: Always been bugged (Score:1)
They developed along with "new" ideas of the time like preprocessing doing a database operation to check if an instruction was assembled from a language that allows overloading or not.
Re: (Score:2)
Which company?
Re: (Score:2)
AMD. Zen4 and 5 have no known speculative execution attack vectors, and Zen3 may also be completely immune.
The problem is bigger than we think. (Score:2)
Recent history has seen an absolutely massive amount of computational power added to the global compute pool. And the rate of computational power is growing at rates that are hard to fathom. Companies are literally commissioning nuclear power plants to power the growth.
So what the heck does this have to do with hardware bugs?
Well now more than ever access to massive amounts of compute all for organisations, state and private to toss hardware designs at this compute to be analysed for vulnerabilities and we
Intel Atom FTW (Score:2)
I've recently retired an Intel Atom board from 2010, but I'm keeping it around for a very nice feature: the in-order CPU has none of the Meltdown/Spectre type vulnerabilities. (Meanwhile, I'm also keeping around a laptop from 2005 whose 32-bit Celeron has quite a few of those.) The Atom line later switched to out-of-order CPUs, but this Bonnell microarchitecture hit the sweet spot of having full x86-64 instructions but none of these vulnerabilities.
In light of these security issues, it would be interesti
Re: (Score:2)
You should be able to constrain the reorder buffer of an OOO architecture to a depth of one at runtime.
The performance would suck. There's a reason there's not many high performance in-order designs.
By the way, going multi-core had the same problems as OOO except you only have cache integrity mechanisms on your side.
TFA? (Score:2)