CPU Security Flaws MELTDOWN and SPECTRE

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

  1. Malo

    Malo Yak Mechanicum
    Legend Veteran Subscriber

    Joined:
    Feb 9, 2002
    Messages:
    6,977
    Likes Received:
    3,057
    Location:
    Pennsylvania
    Well they've been at it for 6 months so that's a good indicator AMD is safe with current attack vectors. And with AMD themselves stating without any PR fluff that they're not vulnerable to Meltdown, the powers that be feel that they should be excluded.
     
    BRiT and Cyan like this.
  2. matthias

    Newcomer

    Joined:
    May 19, 2010
    Messages:
    32
    Likes Received:
    22
    Location:
    Germany
    The performance implications for datacenters after meltdown patches are massive. Who will pay the higher cost? This could get nasty.
     
    DeeJayBump, Cyan, milk and 1 other person like this.
  3. Gubbi

    Veteran

    Joined:
    Feb 8, 2002
    Messages:
    3,519
    Likes Received:
    852
    Pretty devastating for Intel in shared kernel cloud environments (Linux.docker, BSD.jails). There is really no safe way to run without PTI. Stuff that does a lot of io suffer the most; du: 50% negative impact, Postgres: 17-23%. That's two or more CPU generations worth of performance.

    Cheers
     
    BRiT, Mize, Cyan and 1 other person like this.
  4. msxyz

    Newcomer

    Joined:
    May 5, 2006
    Messages:
    112
    Likes Received:
    46
    Since these attacks exploit a 'design quirk' in the implementation of speculative execution inside the CPU pipeline, it would be interesting to know on how many different processors and architectures the attack would be reproducible. While ARM processors take the lions share in today, there are still countless devices using some kind of PowerPC variant (and a simplified Linux as OS). Would those devices equally at risk?

    On a side note, in the x86 space, speculative execution has been employed since mid '90s (P6 and 6x86) and the concept is even older and certainly not limited to x86 architectures.
    Why nobody came up with this concept of attack before? Is this vulnerability a consequence of a CPU design fault, or something has changed at OS level, in the last few years, that made this attack possible?
     
  5. Cyan

    Cyan orange
    Legend Veteran

    Joined:
    Apr 24, 2007
    Messages:
    8,572
    Likes Received:
    2,290
    well, KB4056892 is the critical update with the fix and it appeared ready to download in my Intel devices, my tablet and my laptop, but not on my AMD Ryzen 1500X computer. It may well be critical 'cos I built a 6 Vega 56 rig for another person using a pirate little pirate and creepy version of Windows 10 and the update appeared ready to install there (I had disabled automatic Windows updates and had to enable the service again, and voilá it was there).
     
  6. Kaotik

    Kaotik Drunk Member
    Legend

    Joined:
    Apr 16, 2003
    Messages:
    8,166
    Likes Received:
    1,836
    Location:
    Finland
    The patch should come on every rig regardless of the CPU, It includes other stuff besides this fix, too.
    If it's not installed within 24h of the patch release you either have incompatible antivirus or whichever AV you use (including built-in Defender) forgot to add the reg key which tells it's compatible with the patch
    Code:
    Key=”HKEY_LOCAL_MACHINE” Subkey=”SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat” Value=”cadca5fe-87d3-4b96-b7fb-a231484277cc” Type=”REG_DWORD”
     
    Lightman and Cyan like this.
  7. Malo

    Malo Yak Mechanicum
    Legend Veteran Subscriber

    Joined:
    Feb 9, 2002
    Messages:
    6,977
    Likes Received:
    3,057
    Location:
    Pennsylvania
    Microsoft don't turn on the floodgates for windows updates. Keep in mind this goes out to hundreds of millions of computers. Not everyone will get it at the same time so it's not really an indication of exclusion. I also assume the patch would go out irrespective and if there is an exclusion for AMD, it would be in the code. That way if you decide to move the drive to new PC build with an Intel, the patch would already be in place.
     
    BRiT likes this.
  8. Cyan

    Cyan orange
    Legend Veteran

    Joined:
    Apr 24, 2007
    Messages:
    8,572
    Likes Received:
    2,290
    shall take a look again then.... Maybe it's not as critical as an update as in Intel machines? Checked again, the computer says "Your device is up to date". Of note is the fact that all the computers I have use the built in Defender av.
     
  9. Malo

    Malo Yak Mechanicum
    Legend Veteran Subscriber

    Joined:
    Feb 9, 2002
    Messages:
    6,977
    Likes Received:
    3,057
    Location:
    Pennsylvania
    To confirm my assumptions, 2 out of 4 of my Intel Windows 10 PCs have received the patch so far, and my Ryzen Windows 10 PC received it as well. It's just the usual update queues so it's not completely overloading servers.
     
    BRiT and Lightman like this.
  10. Grall

    Grall Invisible Member
    Legend

    Joined:
    Apr 14, 2002
    Messages:
    10,801
    Likes Received:
    2,172
    Location:
    La-la land
    As always, ultimately it will be the end users, IE you and me... :p

    Intel rig here, and my windows update says my PC is up to date too. So don't fret, you'll get the patch soon enough...
     
    Cyan likes this.
  11. Grall

    Grall Invisible Member
    Legend

    Joined:
    Apr 14, 2002
    Messages:
    10,801
    Likes Received:
    2,172
    Location:
    La-la land
    Did the patch knock a chunk of performance off of your rig, or is Ryzen patch just a "coke light" version for the first vulnerability AMD confirmed they were susceptible to?
     
  12. entity279

    Veteran Regular Subscriber

    Joined:
    May 12, 2008
    Messages:
    1,229
    Likes Received:
    422
    Location:
    Romania
    Well, for desktops there isn't supposed to be any tangible performance loss. So all good, we're not running databases and virtualization servers too much i'd hope
     
  13. Gipsel

    Veteran

    Joined:
    Jan 4, 2010
    Messages:
    1,620
    Likes Received:
    264
    Location:
    Hamburg, Germany
    Well the last part of that quote from the meltdown paper is arguably wrong (edit: as long as that means instructions with memory references which are prone to side channel attacks; a speculative add with register operands or something may happen, but it would have no detectable side effects as it is completely rolled back). Their toy example just shows that one may leak data through out of order speculative execution without crossing privilege levels (=> may be used to create roughly the same effect as spectre variant 1). The data value "leaked" in that toy example is (legally) accessible to the toy example program (it is actually part of it). AMD's hedge against meltdown is basically this: "Our CPUs don't speculate using memory references pointing to locations restricted to higher privilege levels than the running code". And the results (no success to exfiltrate kernel memory with that approach) appear to support that.
     
    #73 Gipsel, Jan 4, 2018
    Last edited: Jan 4, 2018
    DavidGraham, DeeJayBump and matthias like this.
  14. Malo

    Malo Yak Mechanicum
    Legend Veteran Subscriber

    Joined:
    Feb 9, 2002
    Messages:
    6,977
    Likes Received:
    3,057
    Location:
    Pennsylvania
    Since I didn't perform any pre-patch benchmarking across different types of applications (apart from quick SSD test), I don't really know and I highly doubt it looking at some testing done so far by sources. Since I/O was apparently a factor, I did a quick SSD performance test a few times in my SSD utility, averaging the results, then did them again post-patch with no difference in reads or writes for 128kb or 4kb sizes.
     
    Grall likes this.
  15. 3dilettante

    Legend Alpha

    Joined:
    Sep 15, 2003
    Messages:
    8,122
    Likes Received:
    2,873
    Location:
    Well within 3d
    It's quite possible this specific vector won't hit AMD, for now.
    Perversely, this exemption may lead to AMD systems becoming less secure over time if additional attacks on KASLR or some other exploit that can be preempted if the kernel is generally unavailable in user space comes along, since that was the original intent of the isolation changes. Additionally, the isolation changes may be the basis for further mitigation strategies for the side-channel attacks mentioned in some of the KAISER proposal's source documents that AMD was vulnerable to but were ignored or listed as "future work".

    I think it would behoove AMD to operate under the assumption that it won't enjoy a status of being a beneficiary of a less expensive but provably less safe memory mapping decision forever.
    Frankly, it may behoove AMD and Intel, or perhaps many stakeholders in hardware and software, to make some decisions about how to define and manage not just instruction or execution semantics, but the characterization and management of how knowable the behaviors or history a given section of the system or stretches of code can be.

    Multiple trends, such as:
    • high-precision timers
    • desire for more performance in more complex system corners (need to optimize where things haven't been highly optimized, like system calls, synchronization, load/store hazards, correlating behavior across domains)
    • desire for better profiling, tuning, self-management (perf counters, trace data, event records)
    • desire for easier development and support
    • power efficiency/performance (ex. aliasing to simplify hardware and save power, power/clock management)
    • the increasing difficulty in exploiting browsers and operating systems
    • virtualization (reduce overhead, latency in a manner that interacts with virtual memory and OS)
    • hardened software leaning more heavily on isolation measures leveraging the kernel
    • different cycles in hardware design versus software
    • different cadences or silo-ed communication for the individual speculation measures
    • increasingly sophisticated nation-state and criminal organizations for IT crime
    • maturation of data technologies and large revenues in businesses using data or making data a business
    • time it took to take research from academic curiosity and realize it had broader potential
    • the rise of server/cloud infrastructure that ripped out the original assumptions about local control of the hardware
    And so on.
    I have some thoughts on what some mitigations could be in the future, but also what that might mean for designing and understanding these systems or developing for them. Being able to reason about system behavior and performance, or to understand why things may fall apart cuts both ways, as it's a question of what someone is able to know, and the power that knowledge imparts is directed based on the motivation of the person that has it.

    Also, I'm curious about in-order architectures with run-ahead, or in-order architectures with explicit speculation measures that might have side effects, or what other ARM vendors (Nvidia Denver, Samsung's M cores, Qualcomm's server, etc.)

    Similarly, if I have time I need to get some references on discussions about hardware speculation, speculation in general, and hardware/software management of system functions.
    Linus Torvalds' strong words about speculation remind me of a raft of discussions about dynamic vs static performance measures, prediction vs predication or conditional moves, software vs hardware TLB management, weak memory ordering versus strong ordering with speculation, the decision by Linux and others to have kernel and user memory mappings in the same space, etc.
    In isolation, I've found a number of such arguments interesting and compelling, but there's an interesting emergent property to when all those items came together--and then at some point everything was different.
     
    Kej, BRiT, Silent_Buddha and 2 others like this.
  16. swaaye

    swaaye Entirely Suboptimal
    Legend

    Joined:
    Mar 15, 2003
    Messages:
    8,456
    Likes Received:
    578
    Location:
    WI, USA
    It's unfortunate that Nexus 9 support (NV Denver) recently ended. Right before KRACK too. What a mess security is these days. Lineage at least addressed KRACK in their distribution.

    I wonder if NV Shield Tablet will get a security update. That uses Cortex A15. They did one for KRACK but really they have ended support for the tablet. I imagine the TV device will get something since they still sell it.

    Android's shit end user support gets scarier every day. So many devices in use out there that have loads of exploits.
     
    #76 swaaye, Jan 4, 2018
    Last edited: Jan 4, 2018
    BRiT likes this.
  17. 3dilettante

    Legend Alpha

    Joined:
    Sep 15, 2003
    Messages:
    8,122
    Likes Received:
    2,873
    Location:
    Well within 3d
    Nvidia's Denver might be subject to some variation on Spectre, although at two levels given its recompilation method coupled with undisclosed branch prediction and runahead execution in the shadow of a data cache miss.
    If sufficient knowledge exists as to the ucode generator's capabilities (it does its own re-ordering and "optimizations" as well) or bugs, it could be possible to leverage Denver's speculation and recovery methods to load the L1, and possibly in a way that the native ARM code path does not leave as an obvious vulnerability.

    For Meltdown, it's not entirely clear when faults handled in the pipeline. If there's a delay in processing a fault to a final exception-handling write-back phase like Intel and maybe the ARM A75, there could be a time window where a dependent bundle can fire off its own skewed load and hit the data cache before the error is found. There's several stages until writeback, although the architecture could have other safeguards.

    Denver does have some kind of transactional handling of writes for its internal bundles, whose handling may or may not have side effects. One possibility, if the data cache is where transactional writes get held, is if that can affect eviction patterns.
    Delayed fault detection that loads a value and uses Denver's read-modify-write capability might evict a line in a carefully prepped data cache before the bundle is aborted, and may have enough signal for timing analysis.

    On the other hand, the ucode generator might be able to implement detection and mitigation for such problems as well, though it may get expensive covering up for software.
     
  18. Malo

    Malo Yak Mechanicum
    Legend Veteran Subscriber

    Joined:
    Feb 9, 2002
    Messages:
    6,977
    Likes Received:
    3,057
    Location:
    Pennsylvania
    Nvidia have already announced that patches for their SoCs are impending, including Shield. They're even building mitigation code into their GPU drivers.
     
    swaaye and Grall like this.
  19. Malo

    Malo Yak Mechanicum
    Legend Veteran Subscriber

    Joined:
    Feb 9, 2002
    Messages:
    6,977
    Likes Received:
    3,057
    Location:
    Pennsylvania
    So I've loaded the patch onto 2 of my Intel systems so far, and my Ryzen system. Looks like the Windows patch doesn't enable the necessary Meltdown protections on my Ryzen since it's not needed:

    Ryzen 1700:
    Speculation control settings for CVE-2017-5754 [rogue data cache load]

    Hardware requires kernel VA shadowing: False

    Both Intel's installed:
    Speculation control settings for CVE-2017-5754 [rogue data cache load]

    Hardware requires kernel VA shadowing: True
    Windows OS support for kernel VA shadow is present: True
    Windows OS support for kernel VA shadow is enabled: True
    Windows OS support for PCID optimization is enabled: False
     
  20. Malo

    Malo Yak Mechanicum
    Legend Veteran Subscriber

    Joined:
    Feb 9, 2002
    Messages:
    6,977
    Likes Received:
    3,057
    Location:
    Pennsylvania
    So now I can answer you with certainty that the patch didn't slow anything down since it does not do anything on AMD CPUs :grin:
     
    Grall and Lightman like this.
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...