Windows and Linux Get Options To Disable Intel TSX To Prevent Zombieload v2 Attacks (zdnet.com) 67
Both Microsoft and the Linux kernel teams have added ways to disable support for Intel Transactional Synchronization Extensions (TSX). From a report: TSX is the Intel technology that opens the company's CPUs to attacks via the Zombieload v2 vulnerability. Zombieload v2 is the codename of a vulnerability that allows malware or a malicious threat actor to extract information processed inside a CPU, information to which they normally shouldn't be able to access due to the security walls present inside modern-day CPUs. This new vulnerability was disclosed earlier this week. Intel said it would release microcode (CPU firmware) updates -- available on the company's Support & Downloads center. But, the reality of a real-world production environment is that performance matters. Past microcode updates for other attacks, such as Meltdown, Spectre, Foreshadow, Fallout, and Zombieload v1, have been known to introduce performance hits of up to 40%. Seeing that all the CPU attacks listed above are not only theoretical but also hard to pull off, some companies don't see this performance hit as an option.
Better fix (Score:5, Insightful)
Buy AMD rather than Intel. There have been a handful of old AMD chips hit by a few of the attacks but overall they are mostly not compromised by these.
Everyone buys AMD nowadays. (Score:3)
I don't think anyone who looks into it, even if just price-wise, chooses Intel these days.
Only inertia and ideology are left.
[Not that I think Intel dying would be a good idea. Maybe a rebirth. Out with the criminals (Yes, given their corporate culture history, that is an accurate description for their leaders), in with the innovators.]
Re:Everyone buys AMD nowadays. (Score:5, Insightful)
Unfortunately, in people that do not really know what they are doing, inertia and ideology are strong. And most corporate buyers have no clue about the products they buy. They just continue to do what the guy before them did and hope nobody notices.
Re: (Score:3)
Even if they intend to, frankly it nearly impossible to keep up with every development underlying every component in the system and that is what you need to do in order to wade beyond what the sales people (who also don't really understand the technology) are telling you.
Just like sales, at best people learn enough to SOUND like they understand what they are talking about.
Re: (Score:2)
Quite frankly, if you do not keep up with the more important developments here, then you are _incompetent_. And no, it is not hard to do either.
Re: (Score:2)
Or more likely you overestimate your own competence.
Re: (Score:1)
AMEN. Unfortunately, after being AMD only for about 10 years, on my last build I decided to give Intel another shot. 6 months later..... I want a refund. lol
Re: (Score:3)
some bypasses may need to be reset on each update (Score:2)
some bypasses may need to be reset on each update manually
Re: (Score:2)
How do you do that on a server? Also its code that being run under the hood constantly.
Re: (Score:2)
Just put a hard-wired interrupt button and hire a monkey to press it occasionally.
It'll be about as fast and cheap, after disabling the troublesome bits and paying the Intel premium.
Re: (Score:3)
That isn't a problem because without these patches the AMD chips still outperform intel AND cost less. These vulnerabilities could lend themselves to situations you don't expect though like code running in a browser gaining information about code that is not.
The biggest problem center though is virtualized/cloud infrastructure. There is supposed to be isolation between VMs and these vulnerabilities allow an opportunity to break that isolation peeking into the state of other systems.
Re: (Score:2)
That's a good question, isn't it? Will cloud providers implement fixes that impact performance, then raise prices to compensate?
Will this impact the cloud value model, compared with on-prem?
Re: (Score:3, Informative)
As the OS (from any modern vendor) is getting more and more secure. Hackers are getting more sophisticated and will target the CPU vs the OS.
1980's "Hacks" were dialing into system that just didn't bother with a password or an easy to guess password, or a virus hidden the executable or boot sector. These were then fixed with Virus checkers, improved OS Security settings, and better policies.
1990's Hacks focused around buffe
Re:Better fix (Score:5, Interesting)
Unlikely. This required a massive screw-up by Intel. Unless AMD has massively screwed up as well (and we would know by now), they are never going to be _this_ vulnerable.
Re: (Score:2)
We kept telling them- if they ever get popular enough, I assure you, people will start targeting them.
Like it or not, AMD is a rather small proportion of extant x86 processors.
They're doing well these days, but they're still not the main target.
So frankly, your assertion that "Unless AMD has massively screwed up as well (and we would know by now)" us pure fantasy, and really kind of laughable. It ignores literally all of computing history
Re: (Score:2)
I remember when dipshits were saying the same thing about Macs. We kept telling them- if they ever get popular enough, I assure you, people will start targeting them.
Even if it is security through obscurity, that is a good thing. Unless you enjoy getting your computer Pwned because it is sooo popular. My goal is to have as few attacks as possible, not to have a popular device.
Re: (Score:2)
I was arguing against the assertion that A is more secure than B because of some inherent design decision of A, rather than the low market penetration of A.
Re: (Score:2)
You do not get my point and you _really_ have no clue about the history of hardware vulnerabilities in computing equipment. Risk is not only determined by attacker motivation, but strongly depends on vulnerability level. Intel has messed this up massively (despite being warned early by research), and that causes a high level of vulnerability on their part. Likely no future design will get it wrong this badly.
Re: (Score:2)
99% of all risk is attacker motivation. Period. All computing history supports this conclusion.
One can make a hypothetical argument for flawless hardware or software security creating a field where the the great leveler is the actual security of the device/software itself, but side channels make that a stupid argument to make. And that's where we're at. Side-channel attacks.
Re:Better fix (Score:5, Insightful)
However the real issue is the popular system is the biggest target and the hack will be written to find its weaknesses.
The real issue here is that the the bigger target got that way by sacrificing security for speed, thereby making it a much easier target. Even if AMD were the bigger target, its design and manufacturing standards would still make it the harder target,
Intel willingly and knowingly retained dangerous flaws in their chip designs so those chips would get to market faster. Intel isn't the biggest target just because it's used more, though that does factor into the equation. It's the biggest target because it's the most used and it's the easiest to exploit.
AMD chips have the same feature set as Intel, yet are more secure. And now, with all the mitigations in place that work around the security Intel should have been putting into their products, AMD chips are also the fastest ones by a large margin. Intel cheat and got caught. AMD was more diligent, and paid for it in the market dominated by the unethical cheater, but should now reap the rewards of that diligence.
Re:Better fix (Score:5, Insightful)
"Intel willingly and knowingly retained dangerous flaws in their chip designs so those chips would get to market faster. Intel isn't the biggest target just because it's used more, though that does factor into the equation. It's the biggest target because it's the most used and it's the easiest to exploit."
And as a consequence nobody should hesitate to switch to AMD on ethical grounds as well. Intel's dominance is an ill-gotten position and they did it by compromising the integrity of all of their customers. Even if they pull ahead at some later point one should think twice before trusting intel. This types of issues aren't always easy to find in a cpu.
Re: (Score:2)
Intel willingly and knowingly retained dangerous flaws in their chip designs so those chips would get to market faster. Intel isn't the biggest target just because it's used more, though that does factor into the equation. It's the biggest target because it's the most used and it's the easiest to exploit.
Intel also abused the process by repeatedly resetting the clock on disclosure after they were notified.
https://mdsattacks.com/#ridl-n... [mdsattacks.com]
Re:Better fix (Score:4)
Then the AMD Chips will become popular targets and their own attacks will be found.
Intel is looking for vulns in AMD chips. Remember when that Intel-affiliated lab in Israel found some? And when a vuln crops up in an Intel chip, people check to see if something similar will work on an AMD chip. In spite of that, AMD is still not vulnerable to MELTDOWN, and is still less-vulnerable to SPECTRE-type attacks. AMD processors are fundamentally more secure by design than Intel Core and derivatives. Further, Intel has brought out several "new" architectures since MELTDOWN was discovered, and all of them are vulnerable to MELTDOWN — which implies that Intel actually doesn't know how to fix these problems. I'd bet that the people who know how it works (and how to fix it) don't work there any more. And it appears that no one wants to go work there and fix it, either. Possibly they assume that management won't actually let them.
Re:Better fix (Score:5, Insightful)
It would be like having a lecture in ethics from prison inmates.
Re: (Score:3)
But if Intel was so good at finding Vulnerabilities in AMD. You think they would find problems in their own products just as easily.
If they find vulns in their own products they just have to mitigate them and take a performance hit. If it's discovered that they know about vulns and don't fix them it's even worse. So they have way more motivation to find vulnerabilities in AMD's products.
Re: (Score:3)
AMD and Intel CPUs have different microarchitectures.
Meltdown is microarchitecture specific. Of course it isn't cross-vendor.
Spectre is not- which is why it is.
Statements like "In spite of that, AMD is still not vulnerable to MELTDOWN" are nothing but ridiculously confident ignorance. Quit being a tool.
Re: (Score:2)
Meltdown is microarchitecture specific. Of course it isn't cross-vendor.
Meltdown is doing-access-checks-after-it's-too-late specific. Intel did that and AMD didn't. That's why it isn't cross-vendor. POWER7 through POWER9 are also vulnerable to MELTDOWN, as are some SPARC architectures. noob.
Re: (Score:2)
It is not special that AMD's x86 microarchitecture didn't succomb to this design flaw, and it implies precisely nothing as to whether design flaws AMDs are more secure by design. It simply means they didn't make this one mistake.
I.e., Spectre-class vulnerabilities have been a random spattering of susceptibility am
Re: (Score:2)
It is not special that AMD's x86 microarchitecture didn't succomb to this design flaw, and it implies precisely nothing as to whether design flaws AMDs are more secure by design.
No, that's exactly what it does imply. In fact, it outright proves that AMD does checks before accesses, while only Intel, IBM, and Sun/Oracle chose to do them afterwards.
Re: (Score:2)
Or when they screwed the pooch on Spectre-NG v4.
So no, it doesn't imply that.
It outright proves that AMD dodged that particular bullet.
Re: (Score:2)
No meltdown is an architectural mistake/bad optimization. But not unique to Intel desigs, some ARM processors also had it.
Re: (Score:2)
The ultimate point, is that Meltdown targeted a specific microarchitectural decision made by a single vendor (known at the time).
The fact that AMD didn't fall prey
Disable all the things (Score:2)
Re: (Score:3)
Go back to real mode for everything.
640K ought to be enough for anybody!
How much slower (Score:2)
How much slower will this make my CPU? We are shaving 2% off here, an another 3% here. After awhile this starts to add up. So how much slower will this make my workstation?
Re:How much slower (Score:5, Funny)
Re: (Score:2)
Yet, the most fashionable HTML5 stuff is way slower than anything ever done in Flash, and I can't disable any of it.
Looking back, Flash being single-threaded was a blessing!
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
30% slower (Score:1)
I don't the exact inpact of this particular patch, but of you run a lot windows or browser tabs, all of the Intel patches will make you run about 30% slower than a similarly priced AMD processor.
Re: (Score:2)
My I9 was free so I really can't complain about it. But if I had to pay for it AMD would probably be the way I went with it now.
Re: (Score:3)
...all of the Intel patches will make you run about 30% slower than a similarly priced AMD processor.
Intel chips sacrificed about 30% of their performance just for the Meltdown patch. Then there was Spectre, and now Zombieload. I would expect a much higher performance hit than a mere 30%.
Re: (Score:2)
We keep finding problems with all these instruction sets -- it's almost like we need a Reduced Instruction Set Computer or something. Just sayin'...
Re: (Score:2)
Almost all of them are related to speculative execution. This isn't really too surprising, as that's a quit difficult problem, logically.
That said, if you can't speculate, your logical capabilities are quite reduced. So what's really important is that the various speculations be separated from what's known. But they require access to your memories. Whoops!
I think the problems would be reduced if speculation happened at a much higher level, which means more separation between the ... can you say CPUs for
Re: (Score:2)
The 90s called, they want their ideas about CPUs back. RISC was all hype and all suck. Get over it.
Re: (Score:1)
Um, you know that the chips in all the phones and gadgets that everyone has are RISC, right?
Re: (Score:2)
RISC was a marketing term from the 90s from all the slow CPU manufacturers to explain why they were still better than Intel, despite being slower. And they were, for a few years. Then they weren't.
Too many nerds fell for that marketing, because any excuse to hate Intel is a good excuse. Like anti-Microsoft hatred, it became a religion and rationality was left behind. The chips in modern phones and gadgets are not made by that marketing alliance of mini-computer makers struggling to hold on to relevance.
Re: (Score:2)
Ouch, well guess this makes Ryzen 9 even better (Score:2)
Hmm maybe it's just me but with the release of Ryzen 9 and all these errors cropping up on Intel, seems like AMDs making a lot of wins. Suddenly the recent Ryzen 9 release looks even better.
"Theoretical" "hard to pull off" (Score:2)
Why then do people mention this Javascript browser exploit / demo then?
Now I have contradictory information.
And all spying organizations in the world having motivation to call it theoretical and hard when they did pull it off, does not make that sit well.
Does somebody have a link to this in-browser exploit / demo everyone is always talking about?
(And remember: Reality has dual-binary logic: A lack of such a link does not mean it does not exist. But merely that we do not know if one exists, and have hence no
Will intel force this on by deafalt on AMD systems (Score:2)
Will intel force this on by default on AMD systems
Wow - no one said this already? (Score:2)
Just "double tap" the mouse button to prevent the zombieland attack...
It's gonna be RISC (Score:2)
Aside from the creepy music and announcer, there are some good points made here:
https://www.youtube.com/watch?... [youtube.com]
Are we benchmarking with all this shit enabled? (Score:2)
Are the benchmarking programs reporting on the presence/absence of these patches?
Because I think the liars would lie about this.
Re: (Score:2)
Are the benchmarking programs reporting on the presence/absence of these patches?
There are tons of benchmarks out there for mitigating strategies of every problem known, AMD and Intel, and performance costs of them. Are some people lying about them? Probably- it's the internet. But reputable benchmarks are easy to come by.
TSX vs Performance... not a hard call to make (Score:2)
As a regular system administrator, you'd probably prefer to disable TSX rather than take a performance hit from a firmware/microcode fix.
Hardly anything uses TSX yet. Sure, it's been around for a while now, but it's never worked right. The first generation was screwed up as well.
Errata, security issues, and then more of the same... I genuinely feel bad for any developers who actually want to use this tech in their work.
Re: (Score:3)