CPU Security Flaws MELTDOWN and SPECTRE

DavidGraham said:
Yeah, which means an i7 8700K will probably lose more.
Click to expand...

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 ;)
 
entity279 said:
Your initial advertising of a 10 % drop in Witcher produced far too catastrophical vibes, which I tried to correct by providing some context ;)
Click to expand...
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.
 
DavidGraham said:
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.
Click to expand...

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.
 
entity279 said:
But it'a @ 1080p with a high end card, fps > 100, and they made attepmts to make it CPU limited.
Click to expand...

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.
 
Svensk Viking said:
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.
Click to expand...

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..
 
Dygaza said:
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.
Click to expand...

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
 
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! :D
 
entity279 said:
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
Click to expand...
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))
 
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/
 
Last edited:
3dilettante said:
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.
Click to expand...

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
 
Gubbi said:
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.
Click to expand...
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.

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.
Click to expand...
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.

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.
Click to expand...
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
 
Last edited:
An Update on AMD Processor Security

At AMD, security is our top priority and we are continually working to ensure the safety of our users as new risks arise. As a part of that vigilance, I wanted to update the community on our actions to address the situation.

Google Project Zero (GPZ) Variant 1 (Bounds Check Bypass or Spectre) is applicable to AMD processors.
  • We believe this threat can be contained with an operating system (OS) patch and we have been working with OS providers to address this issue.
  • Microsoft is distributing patches for the majority of AMD systems now. We are working closely with them to correct an issue that paused the distribution of patches for some older AMD processors (AMD Opteron, Athlon and AMD Turion X2 Ultra families) earlier this week. We expect this issue to be corrected shortly and Microsoft should resume updates for these older processors by next week. For the latest details, please see Microsoft’s website.
Linux vendors are also rolling out patches across AMD products now.

GPZ Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors.
  • While we believe that AMD’s processor architectures make it difficult to exploit Variant 2, we continue to work closely with the industry on this threat. We have defined additional steps through a combination of processor microcode updates and OS patches that we will make available to AMD customers and partners to further mitigate the threat.
  • AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks. These software updates will be provided by system providers and OS vendors; please check with your supplier for the latest information on the available option for your configuration and requirements.
  • Linux vendors have begun to roll out OS patches for AMD systems, and we are working closely with Microsoft on the timing for distributing their patches. We are also engaging closely with the Linux community on development of “return trampoline” (Retpoline) software mitigations.

GPZ Variant 3 (Rogue Data Cache Load or Meltdown) is not applicable to AMD processors.
  • We believe AMD processors are not susceptible due to our use of privilege level protections within paging architecture and no mitigation is required
.

There have also been questions about GPU architectures. AMD Radeon GPU architectures do not use speculative execution and thus are not susceptible to these threats.
Click to expand...
 
You must log in or register to reply here.
Back
Top