CPU Security Flaws MELTDOWN and SPECTRE

Discussion in 'PC Industry' started by Bondrewd, Jan 2, 2018.

  1. DavidGraham

    Veteran

    Joined:
    Dec 22, 2009
    Messages:
    3,663
    Likes Received:
    4,471
    Yeah, which means an i7 8700K will probably lose more.
     
  2. Svensk Viking

    Regular

    Joined:
    Oct 11, 2009
    Messages:
    601
    Likes Received:
    183
    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/
     
  3. entity279

    Veteran Regular Subscriber

    Joined:
    May 12, 2008
    Messages:
    1,306
    Likes Received:
    483
    Location:
    Romania
    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 ;)
     
  4. DavidGraham

    Veteran

    Joined:
    Dec 22, 2009
    Messages:
    3,663
    Likes Received:
    4,471
    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.
     
    pharma and Lightman like this.
  5. entity279

    Veteran Regular Subscriber

    Joined:
    May 12, 2008
    Messages:
    1,306
    Likes Received:
    483
    Location:
    Romania
    But it'a @ 1080p with a high end card, fps > 100, and they made attepmts to make it CPU limited.
     
  6. Svensk Viking

    Regular

    Joined:
    Oct 11, 2009
    Messages:
    601
    Likes Received:
    183
    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.
     
    pharma and DavidGraham like this.
  7. Dygaza

    Newcomer

    Joined:
    Aug 27, 2015
    Messages:
    40
    Likes Received:
    39
    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.
     
    DavidGraham likes this.
  8. HMBR

    Regular

    Joined:
    Mar 24, 2009
    Messages:
    418
    Likes Received:
    106
    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..
     
  9. entity279

    Veteran Regular Subscriber

    Joined:
    May 12, 2008
    Messages:
    1,306
    Likes Received:
    483
    Location:
    Romania
    Plenty of people who own >= 120 Hz monitors?

    Not saying that is wrong, but it's far from typical
     
  10. Rodéric

    Rodéric a.k.a. Ingenu
    Moderator Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,068
    Likes Received:
    971
    Location:
    Planet Earth.
    What is the performance impact on Ryzen ?
    Any reliable benchmarks out there ?
    (Is the patch Intel specific of does it touch all CPU ?)
     
  11. Gubbi

    Veteran

    Joined:
    Feb 8, 2002
    Messages:
    3,638
    Likes Received:
    1,075
    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
     
    Lightman likes this.
  12. entity279

    Veteran Regular Subscriber

    Joined:
    May 12, 2008
    Messages:
    1,306
    Likes Received:
    483
    Location:
    Romania
  13. msxyz

    Newcomer

    Joined:
    May 5, 2006
    Messages:
    122
    Likes Received:
    54
    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
     
    Kej, pharma, BRiT and 1 other person like this.
  14. CSI PC

    Veteran Newcomer

    Joined:
    Sep 2, 2015
    Messages:
    2,050
    Likes Received:
    844
    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.
     
  15. Kaotik

    Kaotik Drunk Member
    Legend

    Joined:
    Apr 16, 2003
    Messages:
    9,980
    Likes Received:
    4,178
    Location:
    Finland
    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))
     
  16. entity279

    Veteran Regular Subscriber

    Joined:
    May 12, 2008
    Messages:
    1,306
    Likes Received:
    483
    Location:
    Romania
    Where are some credible Ryzen tests ?

    AFAIK, latest OS updates don't force Meldown fixes on Ryzen
     
  17. 3dilettante

    Legend Alpha

    Joined:
    Sep 15, 2003
    Messages:
    8,562
    Likes Received:
    4,739
    Location:
    Well within 3d
    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/
     
    #137 3dilettante, Jan 11, 2018
    Last edited: Jan 11, 2018
    CSI PC, BRiT and swaaye like this.
  18. Gubbi

    Veteran

    Joined:
    Feb 8, 2002
    Messages:
    3,638
    Likes Received:
    1,075
    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
     
    milk likes this.
  19. 3dilettante

    Legend Alpha

    Joined:
    Sep 15, 2003
    Messages:
    8,562
    Likes Received:
    4,739
    Location:
    Well within 3d
    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
     
    #139 3dilettante, Jan 12, 2018
    Last edited: Jan 12, 2018
  20. Arnold Beckenbauer

    Veteran Subscriber

    Joined:
    Oct 11, 2006
    Messages:
    1,711
    Likes Received:
    667
    Location:
    Germany
    An Update on AMD Processor Security

     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...