4 ms·

I also think it was a PR coup from the Intel side. I think of myself as pretty much tech savvy. But even I hesitated for a moment and asked myself whether AMD w

I also think it was a PR coup from the Intel side. I think of myself as pretty much tech savvy. But even I hesitated for a moment and asked myself whether AMD was affected by meltdown although I knew that it didn't. All the google searches lead to sites mentioning "Meltdown/Spectre attacks" as if they were the same thing. You can hardly find sites that explicitly state: look here is meltdown, it only affects intel CPUs and it can only really be patched on the software level and that will result in HUGE perormance losses. Basically every time your CPU accesses the Kernel Space, some kind of cache cleansing needs to be done, it has to context switch. Instead no one seems to grasp what meltdown is, intel is feeding the media with benchmarks and says there is no real impact, users believe intel. I read somewhere that all big companies Google, Intel etc. knew about these security vulnerabilities, especially meltdown months before. Intel made a deal with Microsoft to disclose the vulnerability on a Microsoft Update date and tell everyone that there was an issue and it was fixed. Microsoft was also supposed to make all processors including AMD to get affected by the slowdown. However Google reported 1 week earlier said it couldn't keep this a secret with good conscience. But even if that plan failed there is still a lot of misinformation caused partly by intel. Even if you visit sites such as meltdownattack.com (first result on google with some deeper info), it says we do not know in which aspect Meltdown affects processors. I'm on the verge of buying a new desktop, I will go with intel because I have no other cheap choice. Intel still delivers the cheapest option for me (i3-8100). But I would appreciate if Intel played fairly. All this manipulation behind the scenes is corrupting the market and intel is responsible for it. I don't know what we got ourselves into. The RAM folks built a cartel and are keeping the prices high. Microsoft is deliberately crippling third party antivirus software. Intel is shipping us CPUs with backdoors (Intel ME), there are serious vulnerabilities that get swept under the rug, yet we have to buy intel because we are locked into the x86 platform. At least microsoft is teaming up with Qualcomm and Apple is rolling out its own ARM processors. We need to have an alternative. IMHO Intel has been playing an unfair and an unethical game.

scott_s 9y ago
But here's the other thing: there is no Meltdown exploit for AMD yet. The paper (https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf, Section 6.4) is clear that the race condition at the core of the exploit exists in AMD chips, as toy examples show some information leakage. It's just that they can't get a working exploit. Is there no working AMD exploit by design, or did AMD just get lucky? I bet they just got lucky.
- ChrisSD 9y ago
  It's by design in a literal sense. AMD enforces security boundaries even with speculative execution. So does ARM on all but a couple of chips.
  - scott_s 9y ago
    I'm talking about Meltdown, which is about a race condition with memory access checking and out-of-order execution, not speculative execution. The paper authors do not give a categorical explanation for why they can't exploit the AMD and ARM chips (Section 6.4), and indicate it may be possible to find an exploit in the future.
    - BeeOnRope 9y ago
      It's still speculative execution: Meltdown works because you can speculatively load a location based on an earlier load which will ultimately fault. That's basically the definition of speculative execution: the second load never even occurs in the non-speculative instruction flow. It is also due to memory access checking and out-of-order execution, since those aren't orthogonal to "speculative execution" (and in fact are tightly related).
      - scott_s 9y ago
        Now we're arguing the semantics of "speculative execution." When I use the term, I mean speculatively executing code across branch instructions. I use "out-of-order execution" when instructions inside of a basic block are executed in an order different from how they appear in the instruction stream. This is the terminology I learned in computer architecture courses, it's what I've read in the literature, and it's what the Meltdown and Spectre authors use.
        BeeOnRope 9y ago
        Well long before these attacks that term had a widely accepted definition in CPU architecture that includes much more than only execution on the other side of a predicted branch. I can't speak to your computer architecture course and I'm not sure what literature you've read (but it's easy to get the impression that it only relates to branches since a lot of literature might only be addressing that aspect), but the Meltdown authors are clear at least (quoting from the pdf): In practice, CPUs supporting out-of-order execution support running operations speculatively to the extent that the processor’s out-of-order logic processes instructions before the CPU is certain whether the instruction will be needed and committed. They go on to note that for the remainder of this paper their use of the term will refer to a more restricted definition related specifically to branch speculation, since that's what they care about. That's fine, and it's good they are clear about it - but it doesn't change the recognized meaning of the term (and indeed their narrowing of the term helps confirms the general definition). They aren't as clear in the Spectre paper, and they focus on branch-related speculative execution since that's what they care about for the purposes of their description, but they don't contradict the idea that speculative execution is limited to branch prediction. Not that the Spectre/Meltdown authors are a particularly authoritative reference for CPU architecture terminology: these are, after all, software guys peeking into the hardware world for the purpose of putting together these attacks. Modern "big" cores are, conceptually, executing most of their instructions speculatively, since wide out-of-order execution windows that that there is a large-degree of divergence from pure in-order and any time any earlier instruction can fault, the remaining instructions are speculative (and the CPU mostly doesn't care: the infrastructure such as the ROB are going to be used regardless of whether the current head of the instruction stream is speculatively or not).

scott_s 9y ago

But here's the other thing: there is no Meltdown exploit for AMD yet. The paper (https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf, Section 6.4) is clear that the race condition at the core of the exploit exists in AMD chips, as toy examples show some information leakage. It's just that they can't get a working exploit. Is there no working AMD exploit by design, or did AMD just get lucky? I bet they just got lucky.

ChrisSD 9y ago
It's by design in a literal sense. AMD enforces security boundaries even with speculative execution. So does ARM on all but a couple of chips.
- scott_s 9y ago
  I'm talking about Meltdown, which is about a race condition with memory access checking and out-of-order execution, not speculative execution. The paper authors do not give a categorical explanation for why they can't exploit the AMD and ARM chips (Section 6.4), and indicate it may be possible to find an exploit in the future.
  - BeeOnRope 9y ago
    It's still speculative execution: Meltdown works because you can speculatively load a location based on an earlier load which will ultimately fault. That's basically the definition of speculative execution: the second load never even occurs in the non-speculative instruction flow. It is also due to memory access checking and out-of-order execution, since those aren't orthogonal to "speculative execution" (and in fact are tightly related).
    - scott_s 9y ago
      Now we're arguing the semantics of "speculative execution." When I use the term, I mean speculatively executing code across branch instructions. I use "out-of-order execution" when instructions inside of a basic block are executed in an order different from how they appear in the instruction stream. This is the terminology I learned in computer architecture courses, it's what I've read in the literature, and it's what the Meltdown and Spectre authors use.
      - BeeOnRope 9y ago
        Well long before these attacks that term had a widely accepted definition in CPU architecture that includes much more than only execution on the other side of a predicted branch. I can't speak to your computer architecture course and I'm not sure what literature you've read (but it's easy to get the impression that it only relates to branches since a lot of literature might only be addressing that aspect), but the Meltdown authors are clear at least (quoting from the pdf): In practice, CPUs supporting out-of-order execution support running operations speculatively to the extent that the processor’s out-of-order logic processes instructions before the CPU is certain whether the instruction will be needed and committed. They go on to note that for the remainder of this paper their use of the term will refer to a more restricted definition related specifically to branch speculation, since that's what they care about. That's fine, and it's good they are clear about it - but it doesn't change the recognized meaning of the term (and indeed their narrowing of the term helps confirms the general definition). They aren't as clear in the Spectre paper, and they focus on branch-related speculative execution since that's what they care about for the purposes of their description, but they don't contradict the idea that speculative execution is limited to branch prediction. Not that the Spectre/Meltdown authors are a particularly authoritative reference for CPU architecture terminology: these are, after all, software guys peeking into the hardware world for the purpose of putting together these attacks. Modern "big" cores are, conceptually, executing most of their instructions speculatively, since wide out-of-order execution windows that that there is a large-degree of divergence from pure in-order and any time any earlier instruction can fault, the remaining instructions are speculative (and the CPU mostly doesn't care: the infrastructure such as the ROB are going to be used regardless of whether the current head of the instruction stream is speculatively or not).