6 ms·

Mill CPU is Immune to Spectre, Meltdown [pdf]

49 points by maxharris 9y ago

remy_luisant 9y ago
Vaporware does tend to be pretty bug-free.
- maxharris 9y ago
  What part of the paper do you take issue with? Can you point to a specific design feature in the linked paper (or in any of the talks on the Mill CPU) that might be vulnerable?
  - wolfgke 9y ago
    > What part of the paper do you take issue with? There exists no Mill CPU - just software models of it at best.
    - gbrown_ 9y ago
      Do you not think it's reasonable to believe that the Mill is immune to these flaws without hardware given the information presented in this paper?
      - wolfgke 9y ago
        It is plausible, but without having a concrete CPU on which independent researchers are able to do independent tests I am rather cautious. Intel, AMD and ARM also claimed that the branch prediction on their CPUs cannot in practise be used to generate a side channel - Spectre proved otherwise.
- acehreli 9y ago
  Not really. :) The Mill has bugs at many levels from design to implementation both in software and hardware. It's even in the linked paper: "A code generator bug exposing a software vulnerability akin to Spectre variant 1 has been resolved with a bug fix, without hardware modifications."
majewsky 9y ago
In the same way that "Code in Haskell is guaranteed to have no side effects"? https://xkcd.com/1312/ https://xkcd.com/1312/
- sli 9y ago
  It's always amusing to look back at failed predictions, even if they're tongue-in-cheek. Surely you're aware that comic was in jest. https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry
emh68 9y ago
Is there an FPGA implementation of a Mill CPU, or even a scaled-down version (32 bits maybe)?
- ac29 9y ago
  Nope, just whitepapers, presentations, and patents.
kbob 9y ago
The paper's findings are more nuanced than the title. 1) The Mill's specializer (effectively a compiler code generator) did have a bug that emitted code susceptible to a Spectre-like attack. The specializer has been fixed. (Fortunately, there's no installed base of Mills to be patched.) 2) The author pointed out that Spectre and Meltdown are specific cases of the general problem: if a cache has any effect on execution speed, it has side effects that can be observed and potentially exploited by an attacker. 3) This paragraph is intriguing for what it doesn't say. > We have internally discussed mitigations to - and elimination of - cache attacks, even before we became aware of the Spectre and Meltdown attacks. A cache that is still an effective cache, but where eviction tells you less or nothing about what evicted it, would be generally immune to all cache attacks. However, we do not have any security enhancements to the general caching problem for disclosure at this time.
- mjn 9y ago
  #1 was the most interesting part of this paper to me. I don't think I've seen a compiler variant of Spectre discussed elsewhere, and now I'm curious whether a similar issue might be present in more mainstream compilers too. The key bit seems to be that a compiler optimization that converts an explicit conditional to branchless code is doing the software-level moral equivalent of speculative execution (because it executes both sides of a conditional, and then throws one side out).
  - runeks 9y ago
    > The key bit seems to be that a compiler optimization that converts an explicit conditional to branchless code is doing the software-level moral equivalent of speculative execution (because it executes both sides of a conditional, and then throws one side out). Isn't speculative execution only a potential problem when the speculative executer has access to memory that the code in question is not supposed to have access to? I.e. compiler-speculative execution, as it were, is not a problem, because the compiler can't reveal anything it doesn't know about (private memory), whereas a CPU can reveal information about private memory because it has access to it.
- gbrown_ 9y ago

49 points by maxharris 9y ago

remy_luisant 9y ago

Vaporware does tend to be pretty bug-free.

maxharris 9y ago
What part of the paper do you take issue with? Can you point to a specific design feature in the linked paper (or in any of the talks on the Mill CPU) that might be vulnerable?
- wolfgke 9y ago
  > What part of the paper do you take issue with? There exists no Mill CPU - just software models of it at best.
  - gbrown_ 9y ago
    Do you not think it's reasonable to believe that the Mill is immune to these flaws without hardware given the information presented in this paper?
    - wolfgke 9y ago
      It is plausible, but without having a concrete CPU on which independent researchers are able to do independent tests I am rather cautious. Intel, AMD and ARM also claimed that the branch prediction on their CPUs cannot in practise be used to generate a side channel - Spectre proved otherwise.
acehreli 9y ago
Not really. :) The Mill has bugs at many levels from design to implementation both in software and hardware. It's even in the linked paper: "A code generator bug exposing a software vulnerability akin to Spectre variant 1 has been resolved with a bug fix, without hardware modifications."

majewsky 9y ago

In the same way that "Code in Haskell is guaranteed to have no side effects"? https://xkcd.com/1312/ https://xkcd.com/1312/

sli 9y ago
It's always amusing to look back at failed predictions, even if they're tongue-in-cheek. Surely you're aware that comic was in jest. https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry

emh68 9y ago

Is there an FPGA implementation of a Mill CPU, or even a scaled-down version (32 bits maybe)?

ac29 9y ago
Nope, just whitepapers, presentations, and patents.

kbob 9y ago

The paper's findings are more nuanced than the title. 1) The Mill's specializer (effectively a compiler code generator) did have a bug that emitted code susceptible to a Spectre-like attack. The specializer has been fixed. (Fortunately, there's no installed base of Mills to be patched.) 2) The author pointed out that Spectre and Meltdown are specific cases of the general problem: if a cache has any effect on execution speed, it has side effects that can be observed and potentially exploited by an attacker. 3) This paragraph is intriguing for what it doesn't say. > We have internally discussed mitigations to - and elimination of - cache attacks, even before we became aware of the Spectre and Meltdown attacks. A cache that is still an effective cache, but where eviction tells you less or nothing about what evicted it, would be generally immune to all cache attacks. However, we do not have any security enhancements to the general caching problem for disclosure at this time.

mjn 9y ago
#1 was the most interesting part of this paper to me. I don't think I've seen a compiler variant of Spectre discussed elsewhere, and now I'm curious whether a similar issue might be present in more mainstream compilers too. The key bit seems to be that a compiler optimization that converts an explicit conditional to branchless code is doing the software-level moral equivalent of speculative execution (because it executes both sides of a conditional, and then throws one side out).
- runeks 9y ago
  > The key bit seems to be that a compiler optimization that converts an explicit conditional to branchless code is doing the software-level moral equivalent of speculative execution (because it executes both sides of a conditional, and then throws one side out). Isn't speculative execution only a potential problem when the speculative executer has access to memory that the code in question is not supposed to have access to? I.e. compiler-speculative execution, as it were, is not a problem, because the compiler can't reveal anything it doesn't know about (private memory), whereas a CPU can reveal information about private memory because it has access to it.
gbrown_ 9y ago