5 ms·

A big difference between impact on Intel and AMD was due to only part of the recent attacks being a new class opening new ground - namely the generic speculativ

• thu2111 6y ago
  Those weren't Intel fails - no CPU manufacturer had any kind of generic rule against that sort of microarchitectural optimisation and it's hard to imagine what sort of rule would have blocked such optimisations by policy which wouldn't also rule out all speculative execution. The only reason AMD wasn't hit by Meltdown too is their cores are/were less optimised.
  • p_l 6y ago
    Moving memory access verification to instruction retirement is the kind of risky optimization one should beware immediately, even if spectre and the like weren't yet known. If only because the risks if you get it wrong are that much higher.
    • rrss 6y ago
      Ok, but "Intel fail" indicates meltdown was specific to Intel processors, when it was also present of IBM and some Arm designs.
      • p_l 6y ago
        I specifically separated the "new class of microarchitecture timing attacks", which was common across many systems (including AMD, POWER and ARM), from "Intel fail" where too aggressive optimization tricks did turn out to be bad idea.
        • jeffbee 6y ago
          "Too aggressive" is just, like, your opinion, man. There are tons of workloads where only maximum throughput or lowest latency are important and the operators of those systems don't care one jot about side channel attacks.
          • wizzwizz4 6y ago
            And PC / general-purpose CPUs aren't such a workload.
            • cthalupa 6y ago
              They aren't? I know a significant number of people who have disabled spectre and meltdown protections in favor of higher performance because they are not concerned at all about side channel attacks. Single tenant workloads that run no untrusted code that are not public facing are not exactly a unicorn.
          • deleted 6y ago
            [deleted]
        • tedunangst 6y ago
          What specific optimization are referring to? The one you mentioned, moving access auth checks to retirement, was something both ARM and POWER did.
          • p_l 6y ago
            Neither ARM nor POWER did that - they had timing side channel from speculative execution (i.e. whether a branch was taken or not). What Intel did was put all memory access auth checks to retirement, so appropriately crafted code could bypass protection bits in TLB, not just snoop elements of cache (AMD, ARM, POWER)
            • rrss 6y ago
              Yes, they did. Intel's implementation of checking permissions in parallel with speculative loads was vulnerable because the transient effects could be observed through cache timing information. All of these attacks, meltdown included, use "timing side channels from speculative execution." POWER9 had the same problem (and therefore was similarly vulnerable to meltdown) for memory accesses that hit in the L1. i.e. userspace accesses to kernel addresses cached in the L1 could produce observable data-dependent effects because the data was available for further speculative execution before the permission exception was raised. This is why the Linux kernel put in place a mitigation for meltdown on POWER CPUs that involves flushing the L1-D cache on transitions to/from kernel space ("RFI flush"). To be clear, the vulnerability that Intel processors have because they "move memory access verification to instruction retirement" is called "meltdown." When I said that meltdown was present on IBM and some Arm designs, I meant that these designs are vulnerable to the same exploit because they have comparable problems with regard to memory permission checks. I was not referring to the various other spectre-type vulnerabilities, which are even more widespread. So to summarize: Ok, but "Intel fail" indicates meltdown was specific to Intel processors, when it was also present of IBM and some Arm designs.
  • csharptwdec19 6y ago
    > The only reason AMD wasn't hit by Meltdown too is their cores are/were less optimised. That doesn't answer whether they were less optimized because someone on the Red team realized that was a good idea.
    • thu2111 6y ago
      There's clearly no such red team, as otherwise they would have blocked various Spectre attacks too, being as they are all variants of the same problem. AMD were taken by surprise like every other vendor, they just got "lucky" with Meltdown.
• avianes 6y ago
  Not sure if the checks of all loads are done at instruction retirement, but yes they are done after the (speculative) execution of the load. We can also talk about the Store-to-Load Forwarding involving a partially check physical address, exploited by the Fallout attack, which is an optimization patented by Intel since 2006 [1]. All these Intel optimizations are old, and sometimes patented (which reduces the chance that IBM, ARM or AMD will do the same) and are totally valid and safe as long as it's assumed that it is impossible to recover data used during the speculative execution. The recovery of this data becomes possible only when the side channel Flush+Reload is discovered in 2014 [2] (which originally didn't target speculative executions). It is only 3 years later that Meltdown attack use Flush+Reload as a covert channel to exfiltrate data during speculative execution. It seems to me that this timeline shows that it was not possible in 2006 to anticipate this issue. So it's not just a lack of education. Perhaps a lack of security research at Intel to continuously challenge their optimizations? But please note that there is no theory to simply determine whether these optimizations are a good idea or not. Criticism is easier afterwards when you know how the attacks are produced. But in 2017 this type of attack was something new. That said, some of Intel's responses to the flaws (partial correction of vulnerabilities, lack of dialogue with researchers, etc.) are very worrying and I think these criticisms are much more legitimate. [1] : https://patents.google.com/patent/US20080082765A1 https://patents.google.com/patent/US20080082765A1 [2] : https://eprint.iacr.org/2013/448.pdf https://eprint.iacr.org/2013/448.pdf
  • p_l 6y ago
    Thanks for the in-depth explanation! I will admit that I'm not an expert in microarchitecture design, so to me the expected flaw would be "we do something wrong in speculative execution and end up bypassing the checks in destructive way", not through side channels. Didn't know about patents involved. And of course timing attacks make everything worse for all of us :/