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,204
    Likes Received:
    402
    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:
    516
    Likes Received:
    129
    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,744
    Likes Received:
    325
  4. rcf

    rcf
    Regular Newcomer

    Joined:
    Nov 6, 2013
    Messages:
    340
    Likes Received:
    269
    Your Hard Drive May Be Listening

     
    Lightman and milk like this.
  5. Esrever

    Regular Newcomer

    Joined:
    Feb 6, 2013
    Messages:
    589
    Likes Received:
    294
    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,744
    Likes Received:
    325
    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,729
    Likes Received:
    99
    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,744
    Likes Received:
    325
    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,729
    Likes Received:
    99
    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,008
    Likes Received:
    2,518
    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.
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...