Retbleed Impact, Overall CPU Security Mitigation Cost For Intel Xeon E3 v5 Skylake

[pWe00Iri3e7Z9lHOX2Qx]

In this particular case, "buy older stuff" may be a valid option too. Anandtech testing showed that strictly in terms of IPC, Skylake was only 2.7% faster on average than Broadwell (the first 14nm part from Intel). Retbleed only impacts gen 6 through gen 8. So you gain a whopping 2.7% with Skylake then promptly lose 11% due to Retbleed. And those old LGA 2011-3 workstations can be had for cheap.

[pWe00Iri3e7Z9lHOX2Qx]

Weird question perhaps, but how does this scale to older hardware? These bugs affect all devices and I wonder his an Intel i7 4770 or i7 9770 handles this.

Perhaps something to test.

Retbleed only impacts Gen 6 to Gen 8 AFAIK.

[Alexmitter]

Based on the past half decade or so I don't think it matters at this point. Just wait a bit and something new will come out that'll hit Zen 4 and Intel Gen whatever is equivalent to that and we'll be discussing Zen 5. Trying to fix x86 like that doesn't seem to be working.

It makes me wonder if something like the Apple M route or pairing architectures is the way to go -- run the OS and "modern" software on the minimal/ARM/RISC CPU and either emulate or add x86 cores that can run unmitigated and isolated from everything else to run "legacy" x86 code.

Inside the CPU, those modern ARM cores and modern x86 are not that different, they just have a different box before the actual CPU that translates whatever CISC instructions into what the actual RISC cores inside understand (intel calls those instructions uOps). x86 CPUs work like this since the days of the Pentium Pro.

What you actually want are simple CPUs that can't do branch predict and do not use any of the other complex speed enhancing logic which you can find in any current x86 or ARM CPU and if you ask, you will find them too in most full featured RISCV cores.

[Adarion]

OMG, that looks partially even nastier than for Zen.
Anyway, I guess retbleet mitigations will see some overhaul, so it won't be THAT bad in the future, but this still hurts.

And OMG, Michael has a new icon! He looks pretty serious on that one. Maybe he'll use it for articles like this?

[redgreen925]

I did my own test a few weeks ago with the mitigations=off set. The only workload I have that matters to me encoding video to x265, the results were close enough to be identical for the work performed with some tiny .?? of FPS difference. I for one fail to see what the problem is supposed to be based on that testing that showed virtually no difference at all. I had thought reading all these doom and gloom postings that some actual performance hit would be there, unless I have a magic CPU that is not working the same as the others it is an i5-9600k.

[F.Ultra]

I did my own test a few weeks ago with the mitigations=off set. The only workload I have that matters to me encoding video to x265, the results were close enough to be identical for the work performed with some tiny .?? of FPS difference. I for one fail to see what the problem is supposed to be based on that testing that showed virtually no difference at all. I had thought reading all these doom and gloom postings that some actual performance hit would be there, unless I have a magic CPU that is not working the same as the others it is an i5-9600k.

encoding video is a 100% userspace cpu task and those are not affected by any of the mitigations what so ever. It's only applications that needs to do lots of syscalls that are really affected, like web servers, database servers and so on. For non server usage there could be potentially a hit when it comes to games but other than that this is mostly about server type of applications and loads.

[birdie]

I did my own test a few weeks ago with the mitigations=off set. The only workload I have that matters to me encoding video to x265, the results were close enough to be identical for the work performed with some tiny .?? of FPS difference. I for one fail to see what the problem is supposed to be based on that testing that showed virtually no difference at all. I had thought reading all these doom and gloom postings that some actual performance hit would be there, unless I have a magic CPU that is not working the same as the others it is an i5-9600k.

Try any JS benchmark and you'll instantly feel the difference. There's a night and day difference for my SkyLake CPU.

The whole system feels a lot snappier with mitigations=off but since I'm a little bit paranoid I don't use the option.

[cjcox]

Digging up my Pentium 233, now marked safe for 2022.

[onlyLinuxLuvUBack]

Based on the past half decade or so I don't think it matters at this point. Just wait a bit and something new will come out that'll hit Zen 4 and Intel Gen whatever is equivalent to that and we'll be discussing Zen 5. Trying to fix x86 like that doesn't seem to be working.

It makes me wonder if something like the Apple M route or pairing architectures is the way to go -- run the OS and "modern" software on the minimal/ARM/RISC CPU and either emulate or add x86 cores that can run unmitigated and isolated from everything else to run "legacy" x86 code.

intel: has us in the 12 years snail increase of performance
amd: hot trashing like we are back in the 80386 buying days, zen4? im already on zen6 throw out your 1 month old cpu trash.

what they should do: there are so many gates avail now they dont know what to do with them, so instead they should hide their x86 cpus behind a castle and mote.
the drawbridge should be a single cpu running temple os, to access the rest of the cores you send your program to temple os and it runs on the hidden farm of cpus.
you could also setup fake facade quad cores of cpus running a swiss cheese windows kernels for low hanging honeypots

[numacross]

Atleast for spectre there was an online test (JS based). So if your running untrusted Code, always use mitigation.

Thanks, I was aware of those and how they were mitigated by relaxing timer accuracy in JavaScript by browser vendors.
I'm just not really convinced of taking up to 50% performance hits in server loads just for the sake of potentially mitigating an attack. It doesn't sound very ecological either...