Results 1 to 9 of 9

Thread: The famous speculative execution security bug

  1. #1

  2. The Following User Says Thank You to Bulat Ziganshin For This Useful Post:

    Kennon Conrad (5th January 2018)

  3. #2
    Member
    Join Date
    Jan 2014
    Location
    Bothell, Washington, USA
    Posts
    685
    Thanks
    153
    Thanked 177 Times in 105 Posts
    How does this go a decade before it is fixed?

  4. #3
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    it's 5 decades now, since the first cpu with speculative execution was ibm 360/91. once it known, the hole looks so obvious what i wonder whether it was really unknown, or just silently exploited by ANB, FSB and the rest

  5. #4
    Member
    Join Date
    Jun 2009
    Location
    Kraków, Poland
    Posts
    1,471
    Thanks
    26
    Thanked 120 Times in 94 Posts
    Not every CPU with speculative execution ignores privilege levels when prefetching data to caches. It's a bug in CPU design, not something inherent to speculative execution.

  6. The Following User Says Thank You to Piotr Tarsa For This Useful Post:

    khavish (10th January 2018)

  7. #5
    Member Alexander Rhatushnyak's Avatar
    Join Date
    Oct 2007
    Location
    Canada
    Posts
    232
    Thanks
    38
    Thanked 80 Times in 43 Posts
    Click image for larger version. 

Name:	DS0i4U4VAAAvbr8.jpg 
Views:	112 
Size:	66.8 KB 
ID:	5625

    This newsgroup is dedicated to image compression:
    http://linkedin.com/groups/Image-Compression-3363256

  8. The Following 2 Users Say Thank You to Alexander Rhatushnyak For This Useful Post:

    encode (9th January 2018),schnaader (10th January 2018)

  9. #6
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    the same bug was detected 12 years ago:
    https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/


    ... and silently ignored

  10. The Following 2 Users Say Thank You to Bulat Ziganshin For This Useful Post:

    encode (9th January 2018),khavish (10th January 2018)

  11. #7
    Member
    Join Date
    Jun 2009
    Location
    Kraków, Poland
    Posts
    1,471
    Thanks
    26
    Thanked 120 Times in 94 Posts
    How is it the same? Does x86 instruction set contain any instruction that violate cache coherence?

  12. #8
    Member
    Join Date
    Nov 2015
    Location
    boot ROM
    Posts
    83
    Thanks
    25
    Thanked 15 Times in 13 Posts
    Quote Originally Posted by Piotr Tarsa View Post
    How is it the same? Does x86 instruction set contain any instruction that violate cache coherence?
    I guess "theoretically" it shouldn't be this way. But most real-world speculative execution implementations proven to be "imperfect". When speculative execution takes place, effects of losing part are supposed to be cancelled, like if it never took place. Yet, illusion is often flawed, one way or another. It happened on many CPUs, x86s from Intel are just one example. AMD swears they aren't vulnerable to most annoying version of this problem (and it is annoying if some lame JavaScript could steal all your passwords from memory and even dump kernel memory it shouldn't be able to touch at all). Still, even AMD suffers from different, less severe but troublesome flaws. They wouldn't take such a huge performance hit Intel is going to undertake though. But it isn't the whole story. Look, high-end ARM64 ICs featuring OoO proven to be affected as well. Low end ARM64 which are in-order execution appear to be "secure". But wait, even RISC-V which is just rising got OoO related problems, lol. The only reason why there was no buzz is that nobody was fast enough to design and sell SoC boasting OoO RISV-V cores affected by bugs. In-order execution things aren't affected, FPGA prototypes would just run fixed cores once these are available, etc.But overall it seems world has wildly missed hazards of OoO deAsigns. Somehow it slipped almost unnoticed. And it took that long. If you think it's all, nope, not a chance. There was RowHammer, almost equally epic thing, targeting DRAM designs itsels. Actually, you can craft plenty of "special" patterns under SW control when HW would perform well below of what you expect. Ever heard of movie you couldn't read back from CD? Drawing certain patterns on your monitor in real time could turn it into (low power) RF transmitter, lol. There is plenty of fun with unintended side use of data, code and HW. Last but not least, the more complicated HW and SW is, the more fragile it gets. Ever heard of aircraft vulns? Nope, it isn't joke, its digital millenium. You can't expect less than that.

  13. The Following User Says Thank You to xcrh For This Useful Post:

    Bulat Ziganshin (12th January 2018)

  14. #9
    Member
    Join Date
    Jun 2009
    Location
    Kraków, Poland
    Posts
    1,471
    Thanks
    26
    Thanked 120 Times in 94 Posts
    I've read about Meltdown and Spectre attacks. They don't rely in any way on cache coherence bugs. At the same time the article specifically says about cache coherence violations:
    The xdcbt instruction was an extended prefetch instruction that fetched straight from memory to the L1 d-cache, skipping L2. This meant that memory coherency was no longer guaranteed, but hey, we’re video game programmers, we know what we’re doing, it will be fine.
    Show me where in the description of Meltdown or Spectre attacks is a discussion about cache coherence violations.

    Problem with Xbox 360 CPU was that there was CPU instruction that violated cache coherence explicitly and by design. It was 100% intentional and it was an performance optimization. It turned out that it caused too much pain, had created much more damage than gain, so developers stopped using it entirely. When they stopped using that instruction the problem was gone. Speculative execution worsened the problem, but it could be alleviated just like Spectre is alleviated today. The code:
    Code:
    if (flags & PREFETCH_EX)
      __xdcbt(src+offset);
    else
      __dcbt(src+offset);
    could be written using masks:
    Code:
    if (use_xdcbt)
    // reserved_space can be prefetched safely
    // if use_xdbct_mask == 0xffffffffh then the following equation reduces to (src+offset)
      __xdcbt(reserved_space + ((src-reserved_space+offset) & use_xdbct_mask));
    else
      __dcbt(src+offset);
    That would remove the problem as even speculative execution of xdcbt would not touch the sensitive cache line as 'use_xdbct_mask' would be 0 anyway and speculatively executed xdbct would prefetch cache line reserved for wrongly taken speculative executions.

    Today we're wiser because we all read about Meltdown and Spectre attacks and their mitigations. Xbox 360 programmers didn't have that luxury so probably they have given up altogether on using problematic instruction instead of using Spectre-like mitigations.

    The key ingredient to Meltdown and Spectre attack is the ability to reconstruct other process' data by observing cache latencies alone (that's the side-channel articles about M&S attacks are telling about). Without that speculative cache loads gains you nothing. You can't read other process' data directly, regardless if your CPU is vulnerable to Meltdown and Spectre attacks or not.

Similar Threads

  1. bug in gipfeli
    By inikep in forum Data Compression
    Replies: 5
    Last Post: 18th November 2015, 22:41
  2. SREP bug - Please Help :(
    By KVM in forum Data Compression
    Replies: 4
    Last Post: 27th October 2015, 16:56
  3. Replies: 1
    Last Post: 28th August 2015, 06:01
  4. Concurrent kernel execution in OpenCL implementations
    By Piotr Tarsa in forum The Off-Topic Lounge
    Replies: 0
    Last Post: 16th April 2011, 16:04
  5. 4x4 bug?
    By m^2 in forum Data Compression
    Replies: 11
    Last Post: 15th November 2008, 20:25

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •