CPU Security Flaws MELTDOWN and SPECTRE

Yeah, which means an i7 8700K will probably lose more.

 

I hope Digitalfoundry updates the test with older CPUs. Their CPU reviews include older processors and have become my go-to site for researching CPU upgrades.

The only test for gaming performance I've seen so far that's using an older CPU is DSOgaming, and that's still a six core HT CPU. AC Origins was the game being impacted significantly in that test.
http://www.dsogaming.com/news/windo...triple-a-games-tested-in-cpu-bound-scenarios/

 

Whatever, the summary remains "no impact or completly ignorable impact" in gaming performance. Your initial advertising of a 10 % drop in Witcher produced far too catastrophical vibes, which I tried to correct by providing some context

 

I get that, but an important game like Witcher 3 losing 10% is nothing to be calm about. Some people pay money for the highest gear just to increase their fps by 10%. For this game to lose this much is unacceptable IMO. This means there will definitely be other games that lose 10% or more as well. This can't be good.

 

But it'a @ 1080p with a high end card, fps > 100, and they made attepmts to make it CPU limited.

 

That's why I'm very eager to see more tests with older CPUs. The i5 2500k is already struggling hitting 60 FPS in Witcher 3, a 10% performance penalty would be terrible for those users.

 

Nothing wrong in that. There are plenty of people who try to run their games at 120 or 144 fps. CPU has huge role in that.

Stranger is that W3 actually suffers more from meltdown patch than the actual microcode update. Microcode effects branch prediction, which should have small effect on single threaded performance.

 

you are not likely to see a difference right now, maybe in the future with more Spectre fixes in place, but with the current windows patch only I doubt.
but I agree that testing slower CPUs would be interesting..

 

Plenty of people who own >= 120 Hz monitors?

Not saying that is wrong, but it's far from typical

 

What is the performance impact on Ryzen ?
Any reliable benchmarks out there ?
(Is the patch Intel specific of does it touch all CPU ?)

 

Here's a single data point.

Doing a du -s . in my software projects folder (613174 files) on Ubuntu 16.04 at work took 885ms pre-patch. Post patch it takes 1086ms, 23% more. The drive is a Samsung MLC sata (not nvme)

CPU is an old i7-2600S

Cheers

 

Dresdenboy tweeted this german article that apparently found IOPS w/ a 960 Pro to be lower by 50% : https://www.heise.de/newsticker/mel...Prozent-ab-SSD-I-O-deutlich-mehr-3938747.html

 

Today I've been able to compile the Spectre proof of concept into a working program under Windows. I've tested it on several Core iX processors from different eras (from Sandy Bridge to Skylake) and the vulnerability is definitively there. The program crashes on a old Intel Core Quad running Windows 7 64, though. After trying several different compiler options, I followed a suggestion I found on a github discussion and replaced the part that invokes the rdtsc and rdtscp commands with a counter loop. By doing this, I've been able to run the modified code also on the machine with the Core Quad processor and retrieve about half of the memory cells the program tries to spoof. Supposedly some people were able to use a similar exploit even on older Pentium M machines. Scary!

On a funny side note, somebody tried running the code on several online C compilers like this: https://www.jdoodle.com/c-online-compiler and it works, too!

 

Yeah reports are saying high performance SSDs modern NVMe ones will be hit hard depending upon the test-scenario.
Also would be interesting to see what effect it has on the Intel Optane cache 16GB/32GB solution and also on their Optane SSDs, their value (yeah not really much of a value but any performance edge som like to get) has probably been destroyed with this patch.

Separately another area that will potentially hit hard, gaming laptops and quite a few use those.

 

Are the Ryzen-tests done on systems which actually just fix what needs to be fixed (aka Spectre variant 1 (theoretically variant 2 too, but since no-one anywhere has been able to get it working on AMD CPUs I don't really see the point))

 

Where are some credible Ryzen tests ?

AFAIK, latest OS updates don't force Meldown fixes on Ryzen

 

I've noted before that I'm it's not safer long term for AMD to be exempt from kernel page table isolation, since the original point was to avoid ineffective KASLR. Perhaps it is a case where the x86 vendors need to come to an agreement in the long-term for how future architectures can better handle KAISER, or provide a path forward for a less hackish version of it.

My point of curiosity about Nvidia's Denver is at least partly satisfied in terms of Denver 2, as Nvidia's latest advisory indicates it has a Meltdown fix.
http://nvidia.custhelp.com/app/answers/detail/a_id/4617
I'm not quite sure, but I think it's applicable to Denver. Nvidia put that core under the Tegra K1 name along with a different chip using ARM, but Nvidia's advisory on that band of products starts naming specific exemptions from Meltdown rather than a blanket indication of inapplicability.

edit:
And IBM Power, for Meltdown and Spectre, maybe.
http://www.zdnet.com/article/meltdo...mware-and-os-fixes-for-vulnerable-power-cpus/

 

Locating kernel pages exploits include TSX and TLB timing attacks. AMD processors don't have TSX. The TLB timing attackes probe the virtual memory space taking advantage of timing differences when translating valid mappings to unmapped regions of the virtual address space. The solution is to have all kinds of translation take the same time. I don't know if this can be fixed in microcode.

AMD processors are immune to the actual leaking of privileged data because memory references are checked for privilege before executed, be it speculatively or by an explicit prefetch instruction.

But as you say, AMD cannot ignore this. KPTI involves unmapping kernel pages and remapping them upon entering the kernel, - expensive on current CPUs. I would expect future processors from Intel to accelerate this un/remapping. A side effect of this will be much faster context switching; Here AMD needs to keep pace.

Cheers

 

There are various cache timing exploits that include exploiting the additional translation caches beyond the TLB or the timing of page data that is left in the caches or evicts an attacker's prepared cache set.
The KPTI changes at least have references to instructions that can purge TLB entries by PCID, and some operations that do that can also go further and clear other translation caches. That's an incomplete solution, as KAISER did not include timing exploits in the primary cache hierarchy.
One additional idea was to normalize the timing of any handling that includes a potential access violation, which would be a software bug or the behavior of hostile probing.
To go further, some of the proposals include breaking the correlation between the virtual and physical addresses associated with the page table hierarchy, which would make knowing the physical address as the caches know it uninformative as to the randomized layout of the kernel's virtual address space.

There's an element of timing in that the specific case AMD suppresses involves an access from user to kernel only, and that wouldn't be known without involving the timing-sensitive items from above.

They could also decide on a superset of the current functionality or a new mode that more explicitly separates the user and kernel spaces as some architectures do. Some hard-wire the distinction straight into the architecture, while the KAISER proposal notes that ARM's having two registers that can be used to track user and kernel separately--rather than one expensive to modify register, may have been a reason for why some timing exploits weren't successful.
While not a full cure, it would allow the hardware to almost immediately quash certain accesses, or allow shortcuts for the hardware to know when user-space accesses need to fall through the TLB hierarchy when in the past they would have hit. That might go further and make changes to how the cache hierarchy receives or retains relevant data.
If the chance presents itself, other mitigation methods proposed above could be accelerated or catered to more effectively.

That's not to go into other possible means of mitigation, like kernel/user dedicated resources.

edit: missing word

 

An Update on AMD Processor Security