3 ms·

I don't think it was malice, but I think it is perfectly fair to say Intel was playing fast and loose here, and they deserve all the flak they're getting as a c

I don't think it was malice, but I think it is perfectly fair to say Intel was playing fast and loose here, and they deserve all the flak they're getting as a consequence. Vulnerabilities like Meltdown and the latest "MDS" vulnerabilities are absolutely a design decision. Think about Meltdown, for example. The problem here was that data from the L1$ memory was forwarded to subsequent instructions during speculative execution even when privilege / permission checks failed. Now the way that an L1$ has to be designed, the TLB lookup happens before reading data from L1$ memory (because you need to know the physical address in order to determine whether there was a cache hit and if so, which line of L1$ to read), and the TLB lookup gives you all the permission bits required to do the permission check. Now you have a choice about what to do when the permission check fails. Either you read the L1$ memory anyway, forward the fact that the permissions check failed separately and rely on later logic to trigger an exception when the instruction would retire. This is clearly what Intel did. Or you can treat this situation more like a cache miss, don't read from L1$ and don't execute subsequent instructions. This seems to be what AMD have done and while it may be slightly more costly (why?), it can't be that much more expensive because you have to track the exception status either way. The point is, at some place in the design a conscious choice was made to allow instructions to continue executing even though a permissions check has failed. The MDS flaws seem similar, though it's a bit harder to judge what exactly was going on there since it's even deeper in microarchitectural details.

dfrage 7y ago
> This is clearly what Intel did. And ARM, and IBM, both the POWER and mainframe/Z teams. Although this design decision of Intel's was in the early 1990s, shipping in their first Pentium Pro in 1995. When AMD's competition was a souped up 486 targeting Intel's superscaler Pentium, although I assume they were also working on their first out-of-order K5 at the time, it first shipping in 1996.
- panarky 7y ago
  > And ARM, and IBM, both the POWER and mainframe/Z teams Is the point of your argument that others did it too, so Intel shouldn't be accountable? Or that others did it too, so it's reasonable to believe that the vulns were impossible to prevent? This argument sounds a lot like the "deflect" part of Facebook's strategy to "delay, deny, deflect".
  - dfrage 7y ago
    I'm saying Intel's design decisions are found in so many other vendors, Spectre in all of them I've looked for, that it represents an industry blind spot. Which calls for different kinds of "accountability", unless you're a rent seeker.
- chx 7y ago
  Nah, the K6 was not an AMD design, it was NexGen. (I had a Nx686 motherboard back in the day. I was young and wasted way too much money on exotic parts. I also had an Ark Logic video card about the same time, it might've been the Hercules Stingray Pro but my memory is a bit fuzzy after 25 years.) https://en.wikipedia.org/wiki/AMD_K6 https://en.wikipedia.org/wiki/AMD_K6 The AMD K6 is a superscalar P5 Pentium-class microprocessor, manufactured by AMD, which superseded the K5. The AMD K6 is based on the Nx686 microprocessor that NexGen was designing when it was acquired by AMD. Despite the name implying a design evolving from the K5, it is in fact a totally different design that was created by the NexGen team, including chief processor architect Greg Favor, and adapted after the AMD purchase.
  - dfrage 7y ago
    That's interesting, and relevant in that the NexGen team was joined by DEC Alpha people to do the K7, but the K6 is not AMD's first out-of-order speculative execution x86 design, per Wikipedia the K5 was an internal project that "was based upon an internal highly parallel 29k RISC processor architecture with an x86 decoding front-end."
cesarb 7y ago
> Now the way that an L1$ has to be designed, the TLB lookup happens before reading data from L1$ memory (because you need to know the physical address in order to determine whether there was a cache hit and if so, which line of L1$ to read) With VIPT caches (which AFAIK both AMD and Intel use for the L1 data cache), the TLB lookup and the L1 cache lookup happen in parallel. The cache lookup uses the bits of the memory address corresponding to the offset within the page (which are unchanged by the translation from virtual to physical addresses) to know which line of the L1 cache to read. Only later, after both the TLB and the L1 cache have returned their results, is the L1 tag compared with the corresponding bits of the physical address returned by the TLB.
- tntn 7y ago
  Still need the tag to know which way to read and whether there is a hit, so the statement is pretty much accurate.
- atq2119 7y ago
  This is only partially correct. A VIPT cache uses the offset into the page to know which set of the L1 cache to read. You still need the result of the TLB to know the line. This is clear from the fact that a page is 4KB while the L1 data cache is 32KB, so the page offset cannot contain enough information to tell the processor which part of L1 to read.

dfrage 7y ago

> This is clearly what Intel did. And ARM, and IBM, both the POWER and mainframe/Z teams. Although this design decision of Intel's was in the early 1990s, shipping in their first Pentium Pro in 1995. When AMD's competition was a souped up 486 targeting Intel's superscaler Pentium, although I assume they were also working on their first out-of-order K5 at the time, it first shipping in 1996.

panarky 7y ago
> And ARM, and IBM, both the POWER and mainframe/Z teams Is the point of your argument that others did it too, so Intel shouldn't be accountable? Or that others did it too, so it's reasonable to believe that the vulns were impossible to prevent? This argument sounds a lot like the "deflect" part of Facebook's strategy to "delay, deny, deflect".
- dfrage 7y ago
  I'm saying Intel's design decisions are found in so many other vendors, Spectre in all of them I've looked for, that it represents an industry blind spot. Which calls for different kinds of "accountability", unless you're a rent seeker.
chx 7y ago
Nah, the K6 was not an AMD design, it was NexGen. (I had a Nx686 motherboard back in the day. I was young and wasted way too much money on exotic parts. I also had an Ark Logic video card about the same time, it might've been the Hercules Stingray Pro but my memory is a bit fuzzy after 25 years.) https://en.wikipedia.org/wiki/AMD_K6 https://en.wikipedia.org/wiki/AMD_K6 The AMD K6 is a superscalar P5 Pentium-class microprocessor, manufactured by AMD, which superseded the K5. The AMD K6 is based on the Nx686 microprocessor that NexGen was designing when it was acquired by AMD. Despite the name implying a design evolving from the K5, it is in fact a totally different design that was created by the NexGen team, including chief processor architect Greg Favor, and adapted after the AMD purchase.
- dfrage 7y ago
  That's interesting, and relevant in that the NexGen team was joined by DEC Alpha people to do the K7, but the K6 is not AMD's first out-of-order speculative execution x86 design, per Wikipedia the K5 was an internal project that "was based upon an internal highly parallel 29k RISC processor architecture with an x86 decoding front-end."

cesarb 7y ago

> Now the way that an L1$ has to be designed, the TLB lookup happens before reading data from L1$ memory (because you need to know the physical address in order to determine whether there was a cache hit and if so, which line of L1$ to read) With VIPT caches (which AFAIK both AMD and Intel use for the L1 data cache), the TLB lookup and the L1 cache lookup happen in parallel. The cache lookup uses the bits of the memory address corresponding to the offset within the page (which are unchanged by the translation from virtual to physical addresses) to know which line of the L1 cache to read. Only later, after both the TLB and the L1 cache have returned their results, is the L1 tag compared with the corresponding bits of the physical address returned by the TLB.

tntn 7y ago
Still need the tag to know which way to read and whether there is a hit, so the statement is pretty much accurate.
atq2119 7y ago
This is only partially correct. A VIPT cache uses the offset into the page to know which set of the L1 cache to read. You still need the result of the TLB to know the line. This is clear from the fact that a page is 4KB while the L1 data cache is 32KB, so the page offset cannot contain enough information to tell the processor which part of L1 to read.