New CrossTalk Attack Impacts Intel's Mobile, Desktop, and Server CPUs (zdnet.com) 40
Academics from a university in the Netherlands have published details today about a new vulnerability in Intel processors. From a report: The security bug, which they named CrossTalk, enables attacker-controlled code executing on one CPU core to leak sensitive data from other software running on a different core. The Vrije University's Systems and Network Security Group (VUSec) says the CrossTalk vulnerability is another type of MDS (microarchitectural data sampling) attack. MDS attacks target user data while in a "transient" state, as it's being processed inside the CPU and its many data-caching systems. More specifically, CrossTalk attacks data while it's being processed by the CPU's Line Fill Buffer (LBF), one of these aforementioned CPU cache systems. According to the VUSec team, the LBF cache actually works with a previously undocumented memory "staging buffer" that is shared by all CPU cores.
Sounds too complicated (Score:2)
CrossTalk vulnerability is another type of MDS (microarchitectural data sampling) attack. MDS attacks target user data while in a "transient" state, as it's being processed inside the CPU and its many data-caching systems. More specifically, CrossTalk attacks data while it's being processed by the CPU's Line Fill Buffer (LBF), one of these aforementioned CPU cache systems.
Instead of getting a PhD to understand that, I'm going to try something else [xkcd.com] on my i7. I'll let you know how it goes, but first, off to the hardware store ...
the easy thing is to go AMD! (Score:3)
the easy thing is to go AMD!
Bloody hell - another one (Score:2)
I think that I will revert to using an abacus in a dark room - at least that was safe :-)
Bah! Humbug! Back to the T3 (Score:2)
Re: (Score:2)
The (late, lamented) Sun T-series processors, up to at least the T3, didn't suffer from this
If you're going to go for a T-series at least opt for a T-800, not those crappy old T3s. Or a T-16 if your problem is womp rats.
Re: (Score:2)
I can see a new kind of optimizing compiler, too: one which tries to group non-dependant instructions together, to allow more out-of-order operations.
Didn't we already try that with Itanium?
Re: (Score:2)
Re: (Score:2)
To be fair to Itanium, wasn't its instruction set at least very RISC like?
Re: (Score:2)
I think that's fair to say, but below the isa was an amazingly complex device.
My main reference is Organik, "A Programmer's view of the Intel 432 System", https://dl.acm.org/doi/book/10... [acm.org] (I still have it). My then employer was looking at it as a platform to run Ada, and was very enthusiastic about avoiding an "impedance mismatch" between the language and the supporting hardware. They persevered for quite a long time: I had left long before they gave up in the itanic (;-))
Re: (Score:3)
The Itanium was a very-long instruction word VLIW architecture. VLIW packed many RISC-like instructions into a much longer instruction word.
The basic problems of VLIW are:
a) An OoO RISC processor can simply grab as many instructions as it can round up, and execute those simultaneously. As the OoO scheduling engine improves between generations, the same code gets faster. For maximum speed, a VLIW processor requires the code be compiled for the specific processor it is running on.
b) The wide instruction
Re: (Score:2)
Actually, it blew up in their face. They're still choking on the bitter pill of having to license x86-amd64. Through HP, they did kill PA-RISC and Alpha.
They just couldn't manage enough thrust to make the pig that was Itanic fly.
Re: (Score:2)
Comment removed (Score:5, Insightful)
Re: (Score:2)
This was forecasted here on Slashdot when the AMD guys came over to contradict Intel's sponsored discussions with their design ideas, including not putting 1+1 at the center of the chip, that's where they put the power connectors. Basically, their ideas are protected by patents Intel can't buy... after up to that point being a chip fab that was depending on Intel's ideas.
Basically, Intel is now lagging... and this is being typed on a Ryzen Threadripper that could use a little more action.
Re: (Score:1)
Actually, it's being typed on an 8051 core attached to whatever other hardware your keyboard is plugged into. Yes, AMD made some of the 8051s, but it's Intel's arch.
Whatever fabless wonder you choose to fancy is up to you.
Re: (Score:1)
AMD up until the Ryzen/Epec chips was totally using Intel ideas... but Intel was forced to license the patents because they couldn't make enough to supply 1999/2000's demand.
Now AMD leads, and Intel is left cleaning up mistakes.
Re:I'll get hate but... (Score:5, Informative)
AMD up until the Ryzen/Epec chips was totally using Intel ideas...
x86-64 is from AMD.... IA-64 from Intel was a mess and was abandoned in favor of AMD design.
Your geek card is revoked permanently
Re: (Score:2)
x86-64 was AMD building on top of Intel's spec... so therefore no patent there. It was their first design change, but it took much later to build a processor that Intel couldn't imitate.
Re: (Score:2)
Re: (Score:1)
You don't even know what an 8051 is, do you?
Re: (Score:3)
Re: (Score:2)
Success breeds failure. The sun rises, the sun sets...
Re: (Score:2)
Intel has been abusing customers for years. Sockets that barely last two generations, Management Engine, removing driver downloads from their web site, and stagnant performance.
AMD may not be perfect but currently Ryzen is a great product and a great proposition.
Re: (Score:2)
Re: (Score:2)
THIS! Basically, don't trust any of those benchmarks.
It amazes me that people act as if this never happened or like there was ever any question about it. I actually tested this when the news broke by patching out the crippler in an ICC compiled binary. The before and after comparison on AMD processors wasn't even close.
Re: (Score:2)
I get you, but it is not clear cut.
ICC optimizes for Intel CPUs, does not cripple AMD on purpose. That is just a "happy coincidence". When you want to take them to court, DoJ will need to prove intentional harm, while Intel can just play ignorance, and say they only have knowledge to optimize for their own CPU architecture, and cannot know how to do a better job on AMD.
CPUs are no longer general purpose. They have specialized instructions for encryption, math, and heck even video encoding and decoding. They
Re: (Score:2)
Re: (Score:2)
Wow! I did not know that.
But that means both parties are really incompetent.
First Intel guys being unable to hide their purpose with simple technical hacks
Second the regulators being unable to do something real against these egregious acts
Re: (Score:2)
Re: (Score:2)
And let's not forget the entire speculative execution fiasco. The main reason Intel turned out to be 15% faster than AMD was that they were cutting corners in terms of security. I even read they had been warned about this, but ignored it.
If you enable the patches then the system usually becomes as slow as the AMD counterparts. But they not advertise these as "optional", i.e.: if you are gaming, ignore security and keep your speed.
Intel needs to hand over chip design to engineers (Score:1)
Intels trouble for a long time now is they have allowed management to lead design and direction of design, until they empower the engineers to lead design and design direction they will continue to have these flaws present in their design, and of course fall further and further behind AMD.
How is this obvious an engineer would never design the Cache system that is present in Intel chips, if the cache was designed by engineers the instructing set would include instructions to control it. This black box cache
Gee, I wonder why Apple might be switching (Score:2)
Apple has enough of their own software security issues without also having to account for Intel's hardware security issues. Just another reason why Apple probably wants to control their desktop silicon.
Probably not (Score:2)
We'll never know why Apple wants to make their own CPUs unless we manage to detect the security holes they will implement in them.