Crap. Makes me wonder how many of these were known by intelligence agencies all this time.

PrMinisterGR:

Crap. Makes me wonder how many of these were known by intelligence agencies all this time.

Don't ask, don't tell.

Maybe it's time for some ground-up architecture design with security at the heart of it...

PrMinisterGR:

Crap. Makes me wonder how many of these were known by intelligence agencies all this time.

They probably knew and had a part in placing these "features" in the CPUs in the first place!

Espionage724:

Of course it's SMT. Why are we still faking cores on 6+ core CPUs, besides bigger numbers looking better? Does anything on consumer platforms benefit enough to warrant SMT enabled by-default?

most games,check out 10400f vs 9400f, differences can be as high as 20-something percent

BLEH!:

Maybe it's time for some ground-up architecture design with security at the heart of it...

Apparently that is no longer possible due to the complexity of modern CPUs. Thankfully, most vulnerabilities require some sort of physical access, so we are pretty much safe but for companies with tons of servers, this kind of stuff must be a nightmare.

H83:

Apparently that is no longer possible due to the complexity of modern CPUs. Thankfully, most vulnerabilities require some sort of physical access, so we are pretty much safe but for companies with tons of servers, this kind of stuff must be a nightmare.

Would going RISC, or hell, even ternary programming change that at all? Not even remotely my field of expertise, but I think we all have a vested interest given the dependence on tech these days to try and fix this. Abstract ideas (not quantum) will be needed!

BLEH!:

Would going RISC, or hell, even ternary programming change that at all? Not even remotely my field of expertise, but I think we all have a vested interest given the dependence on tech these days to try and fix this. Abstract ideas (not quantum) will be needed!

But x86 is RISC, since the P5.

Espionage724:

Of course it's SMT. Why are we still faking cores on 6+ core CPUs, besides bigger numbers looking better? Does anything on consumer platforms benefit enough to warrant SMT enabled by-default?

The difference its huge, not just FPS. Stuttering is massive when my 5600x has SMT off pushing 144fps in cpu intensive games. 17 years of HT and 5 years of SMT and you have this narrow minded belief on it. Yikes.....

PrMinisterGR:

Crap. Makes me wonder how many of these were known by intelligence agencies all this time.

all of them the NSA has folks embedded at every (meaningful) level of core IT industries. the employers usually don't know.

Horus-Anhur:

But x86 is RISC, since the P5.

Not from instruction set point of view.

I'm so bored of vulnerabilities that require physical access to the device. Vulnerabilities aren't worth anyone's concern if you have to physically be there to exploit them. While the article doesn't mention this, someone on another forum quoted a part of the publication that suggested this is the case. It's even more stupid when the exploit can be fixed via better development practices. At that point, why care at all? That's like writing a program that doesn't hide your password when you type it in - should AMD or Intel be expected to patch the CPU because of developer negligence? In any case, seems like SMT/HT really needs to be ditched. Intel's method has so many security holes that it hardly yields any performance advantage anymore. To my understanding, AMD's method is almost a physically complete second core, in which case: why not just make another physical core?

BLEH!:

Maybe it's time for some ground-up architecture design with security at the heart of it...

Not much point. Might as well just disable most of the features that make these so vulnerable in the first place.

H83:

Apparently that is no longer possible due to the complexity of modern CPUs. Thankfully, most vulnerabilities require some sort of physical access, so we are pretty much safe but for companies with tons of servers, this kind of stuff must be a nightmare.

For most of such companies, you need to go through multiple layers of security. I've been to companies where someone has to let you into the building, you get a body scan, you then get a special keycard, there are security guards patrolling the server room, and there are cameras everywhere. There's no phone connection or wifi in the server room, and nothing is allowed to leave the server room. Many of the servers are not connected to the internet. We're talking server rooms with hundreds of millions or even billions of dollars worth of servers, where you won't be able to extract anything useful out of just any single one of them with anything you can sneak out (especially as things like Kubernetes gets more popular, where a single server might not be processing enough data to be of any use). The easiest way to destroy such an organization is to just play dominoes with the server racks by just pulling all the drawers out. TL;DR: the risk of attempting to exploit these on-site vulnerabilities is too high to be worthwhile, and if you have the opportunity to exploit them, there are easier alternatives.

mbk1969:

Not from instruction set point of view.

It's RISC with microcode and a specific decode stage. But the whole architecture is no longer CISC.

Horus-Anhur:

It's RISC with microcode and a specific decode stage. But the whole architecture is no longer CISC.

Still from software point of view it is CISC. (⊙ˍ⊙)

mbk1969:

Still from software point of view it is CISC. (⊙ˍ⊙)

But the whole execution pipeline is RISC. When comparing ARM to X86 CPUs, in efficiency and performance, this is what matters.

Horus-Anhur:

But the whole execution pipeline is RISC. When comparing ARM to X86 CPUs, in efficiency and performance, this is what matters.

Btw, long time ago I participated in programming of digital signal processor (from Texas Instruments) and its assembler had many variants of instructions where you do some operation on two operands and next operand is loaded into register (simultaneously).

schmidtbag:

Not much point. Might as well just disable most of the features that make these so vulnerable in the first place.

And hence make it slow?

mbk1969:

Btw, long time ago I participated in programming of digital signal processor (from Texas Instruments) and its assembler had many variants of instructions where you do some operation on two operands and next operand is loaded into register (simultaneously).

At this point, asides from the microcode thing, one of the biggest differences in instructions, between ARM and X86 is the fixed length of the instruction set and the opcodes.

BLEH!:

And hence make it slow?

Security always comes at the cost of sacrificing something else, whether that be performance, convenience, privacy, extra resources, your sanity, etc. This applies to literally everything in life. Nearly every single CPU vulnerability came from features that were implemented for the sake of improved performance without the need of additional developer intervention. That last bit is important, because the only other ways to improve performance without threatening security is to: A. Increase clock speeds, which increases power consumption and has an upper-limit B. Increase core count, but not all tasks can be made multi-threaded or parallelized C. Add more instructions, but developers must know how to implement them, and, they have to be practical enough to yield any benefit. This also increases the size and cost of cores, exacerbating the challenges of solution B. D. Decrease the process node to compensate for any of the above This is why both CPUs and GPUs seem to be making very little improvement in IPC or performance-per-watt. Why do you think Intel made AVX512, or the E-cores? Why do you think AMD sacrificed latency for chiplets? If you want a truly secure system, it will be slower. This is not something you can bargain with. That's why many people turn off the mitigations where possible, because they're more concerned about performance than security.

I know someone, who upon learning this, will be quite pleased to find that his decision to grab the R5 3500X will give him the last laugh after all. "QUIP affects all other Ryzen, Athlon, Threadripper, and EPYC processors with SMT. Excluding Ryzen 1, 2 and 3." (???)