CPU Security Flaws MELTDOWN and SPECTRE

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

  1. entity279

    Veteran Regular Subscriber

    Joined:
    May 12, 2008
    Messages:
    1,222
    Likes Received:
    418
    Location:
    Romania
    Note that Intel din't even mentioned the mitigations in the press briefing, they had to be specifically asked for any and all details
     
  2. tunafish

    Regular

    Joined:
    Aug 19, 2011
    Messages:
    537
    Likes Received:
    167
    I think it's more likely they just sell it as a performance upgrade, showing graphs of how the new CPUs are faster than the old ones (that have mitigations on ofc), without mentioning the bugs other than in the small print.
     
    hoom and Lightman like this.
  3. hoom

    Veteran

    Joined:
    Sep 23, 2003
    Messages:
    2,885
    Likes Received:
    448
  4. rcf

    rcf
    Regular Newcomer

    Joined:
    Nov 6, 2013
    Messages:
    366
    Likes Received:
    302
    Your Hard Drive May Be Listening

     
    Lightman and milk like this.
  5. Esrever

    Regular Newcomer

    Joined:
    Feb 6, 2013
    Messages:
    594
    Likes Received:
    298
    New Spectre related exploits for Intel named "SPOILER".
    Intel responds with:
     
    BRiT and pharma like this.
  6. hoom

    Veteran

    Joined:
    Sep 23, 2003
    Messages:
    2,885
    Likes Received:
    448
    So Intels solution to its insecure memory stuff is to rely on software developers & fucking RAM manufacturers to fix it? o_O
     
  7. pcchen

    pcchen Moderator
    Moderator Veteran Subscriber

    Joined:
    Feb 6, 2002
    Messages:
    2,739
    Likes Received:
    105
    Location:
    Taiwan
    Actually, rowhammer is a RAM manufacturer problem. The reason why virtual-to-physical mapping is now believed to be better kept secret (from the process which owns the virtual address) is mostly because of rowhammer. If there's no rowhammer, it'd be practically a non-issue.
     
  8. hoom

    Veteran

    Joined:
    Sep 23, 2003
    Messages:
    2,885
    Likes Received:
    448
    Why then were they unable to reproduce the vulnerability with ARM or AMD?
     
  9. pcchen

    pcchen Moderator
    Moderator Veteran Subscriber

    Joined:
    Feb 6, 2002
    Messages:
    2,739
    Likes Received:
    105
    Location:
    Taiwan
    It doesn't matter. If there's no rowhammer, there's no point in hiding virtual-to-physical mapping from the running process. The fact that some ARM and AMD CPU (note that they don't actually test a lot of different ARM and AMD CPUs, so it's not clear whether newer ARM and AMD CPUs are actually immune) does not leak this information does not change that the whole thing would be a non-issue if there's no rowhammer.

    The reason why CPU and OS have these protections against rowhammer is simply because there are just too many DRAM modules out there are susceptible to rowhammer and it can't be easily fixed. It does not change the fact that rowhammer is a design failure of DRAM modules, not CPU and OS. Once rowhammer resistant DRAM modules become widely available, it'd go back to be a non-issue.
     
  10. 3dilettante

    Legend Alpha

    Joined:
    Sep 15, 2003
    Messages:
    8,098
    Likes Received:
    2,814
    Location:
    Well within 3d
    As previously noted, Rowhammer is a DRAM failure. In the past, bit upsets due to neighboring row accesses would have been a reason to fail DRAM at the factory, and when this was discovered the vulnerable products were not acting in accordance to their specifications. That people have moved to secondary mitigations or software is an indication that the DRAM products affected were too widespread to recall or that the reality going forward was that density would come at the price of discarding old standards of array reliability.

    However, there are notable use cases for knowing the physical memory layout of data like IO, NVRAM (big reason why some key instructions exist), and high-performance code. Memory controllers and DRAM modules have limited ranges where they can provide sustained bandwidth and consistent latency based on the physical access patterns. As such, this is likely too important of a case for software to be denied knowledge of the physical address space. I think OS developers are trying to find ways of providing privilege levels for getting this information, which was something that could be queried or derived rather freely up until recently.
    Besides, this is just one side channel. The cache hierarchies, TLBs, and page table layouts are perhaps further out from the memory reorder buffer, but they have well-documented and not-difficult channels for leaking physical address information. There's no likely change on the horizon for ripping out the x86 virtual memory architecture or changing all caches past the L1 to anything but physical addressing.

    As far as counting on software with secret information to be modified to not have path selection based on hidden values, that's been standard cryptographic practice for decades. Secret values are not to be used by instructions or units whose behavior may change based on the contents, or the usage should be obfuscated by stalls or parallel make-work that creates external behavior that is indistinguishable. New side channels or missed exploits are usually reasons to change the code, since almost all execution outside of these limited exceptions considers this behavior to be unimportant, acceptable, or expected.

    In that regard, certain attacks using physical address leaks would be worse on a system using AMD's recommended setup, since a subset of attacks are related to kernel address space mapping leaks fixed by the KAISER changes repurposed for Meltdown.


    It can come down to specific implementation choices or the algorithm used.
    There may also be northbridge or system-level mitigations for problematic patterns that might make such patterns more difficult to sustain, or might make leaking the physical mapping less impactful.

    The AMD chip I saw listed was Bulldozer, whose specific OoO memory implementation was not really disclosed in years past. There could be corner cases that could correlate physical addresses that just differ from the subset of bits Intel used, or from my recollection discussion for Bulldozer's forwarding and disambiguation schemes were that they were more fragile or obscured by other architectural stalls and pitfalls. The weaker load/store pipeline and the unconventional write-through to a write-combining cache that spilled into an insufficient L2 could provide enough of a shadow to lose modest latency spikes versus a generally high-performance Intel scheme with an isolated set of longer mispredicts or a sub-optimal replay mechanism.
    AMD's Zen has been tested to have a more robust speculation pipeline, although testing may be complicated by other forms of speculation that occur within the register file and renamer prior to getting out to the store queue. The store queue which would function using physical addresses and might have its own layer for speculation that could have a timing side channel.
    The general case is that a subset of bits or a hash function using an unknown number of bits (likely >48 bits) is discussed, meaning there could be gaps that could be exploited to varying degrees if they were as well-known.

    The ARM chip I saw listed was a Qualcomm version of the A73, which is just one ARM core of many. Of note, there is a different store to load forwarding mispredict exploit that AMD, Intel, ARM, and others do have exposure to in various products (variant 4) where measures for restricting speculation on store forwarding exist. Some ARM cores do have microcode changes to expose these methods, so they may have a somewhat different implementation for speculation.

    Of the ARM vendors, I would be curious about Apple. For one thing, Apple's cores are significantly higher-performance, IOS products got Meltdown-related changes as well, and Apple and Intel ran into litigation surrounding the same memory disambiguation patent.
     
    Lightman likes this.
  11. rcf

    rcf
    Regular Newcomer

    Joined:
    Nov 6, 2013
    Messages:
    366
    Likes Received:
    302
    Intel VISA: Through the Rabbit Hole

     
    milk likes this.
  12. Bludd

    Bludd Experiencing A Significant Gravitas Shortfall
    Veteran

    Joined:
    Oct 26, 2003
    Messages:
    3,133
    Likes Received:
    705
    Location:
    Funny, It Worked Last Time...
    milk likes this.
  13. 3dilettante

    Legend Alpha

    Joined:
    Sep 15, 2003
    Messages:
    8,098
    Likes Received:
    2,814
    Location:
    Well within 3d
    The presentation slides go into more detail about the on-die fabric and significant debugging and trace capability.
    There's a primary data fabric that extends PCIe semantics, connects IP blocks, and allows for third-party integration. There's a base fabric unit, various addressing methods, and bridges from the internal fabric to various external or legacy buses.
    Much of this is reminiscent of another vendors more publicly marketed fabric.
    There's also a sideband bus with more miscellaneous traffic and a JTAG bus for testing.

    Various exploits attempt to set system variables to unlock an access level that can reach all levels of fabric, clients, and the signals and tracing available with the VISA infrastructure.
    As noted, these are validation and testing tools for a complex and high-performance collection of internal systems.
    Using this means local access and essentially running a setup for testing and validating the chip--whose wealth of tools and counters can give side-channel information or avenues for touching elements assumed inaccessible outside of a factory test-bench.
    While there seems to be a fuse-based way of locking this out, it appears to be unset.

    I'd be curious what methods other vendors have for this. All such chips would have some kind of infrastructure for validation and testing. Whether they lock things out with more layers of security or physical/electrical barriers like fusing is unclear.
    As an example, when AMD's Ryzen chips were experiencing segfault errors, they were asking for chips to be returned. That could have been an opportunity to analyze what on-die elements were failing, or could serve such a role in any future post-launch problems.

    Possibly, the desire for such a capability may explain why Intel and presumably others might not have made the cut-out for this kind of functionality physical.
     
    Malo likes this.
  14. Esrever

    Regular Newcomer

    Joined:
    Feb 6, 2013
    Messages:
    594
    Likes Received:
    298
    New ZombieLoad attack discovered on Intel CPUs. Whitepaper discuss:

    [​IMG]

    Looks like everything since sandy bridge until kaby lake is affected.

    The demo on the official site is extremely scary, it shows leaking info through an VM on TOR
     
    #354 Esrever, May 14, 2019
    Last edited: May 14, 2019
    BRiT and Lightman like this.
  15. hoom

    Veteran

    Joined:
    Sep 23, 2003
    Messages:
    2,885
    Likes Received:
    448
    New Win 10 update has further Spectre related fixes https://support.microsoft.com/en-nz/help/4494441/windows-10-update-kb4494441
     
    Lightman likes this.
  16. Malo

    Malo Yak Mechanicum
    Legend Veteran Subscriber

    Joined:
    Feb 9, 2002
    Messages:
    6,899
    Likes Received:
    2,965
    Location:
    Pennsylvania
    So I've been reading a perf hit from ZombiLoad around 3% for desktop and up to 9% for datacenter. Some specific workloads on Mac being hit up to 40%.

    Those of us with VPS are being shafted more and more over time as additional fixes are applied by hosts. Maybe Intel should pay for all hosts around the world to bump up all their clients one perf level.
     
  17. BRiT

    BRiT (╯°□°)╯
    Moderator Legend Alpha Subscriber

    Joined:
    Feb 7, 2002
    Messages:
    12,155
    Likes Received:
    8,306
    Location:
    Cleveland
    I haven't followed closely, so can someone gauge the following statement I saw on other forums for truthiness?
    • One of the fixes/patches disables HyperThreading thus downgrading i7's to i5's with major financial impact considering the premium Intel charges between the models.
     
  18. swaaye

    swaaye Entirely Suboptimal
    Legend

    Joined:
    Mar 15, 2003
    Messages:
    8,450
    Likes Received:
    568
    Location:
    WI, USA
    You would still have a larger L3 cache than an i5. :D
     
    #359 swaaye, May 16, 2019
    Last edited: May 16, 2019
  19. Malo

    Malo Yak Mechanicum
    Legend Veteran Subscriber

    Joined:
    Feb 9, 2002
    Messages:
    6,899
    Likes Received:
    2,965
    Location:
    Pennsylvania
    From what I've read so far, ChromeOS is disabling HT in its next update.
     
    iMacmatician likes 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...