Hacker News new | comments | ask | show | jobs | submit login
Mill CPU is Immune to Spectre, Meltdown [pdf] (millcomputing.com)
49 points by maxharris on Jan 15, 2018 | hide | past | web | favorite | 14 comments



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.


#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).


> 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.


The final paragraph caught my eye also with the "disclosure at this time". Understandably Mill presentations have followed the team securing patents so we may see more details on this later. Not sure if anyone from the Mill team may be able to allude as to when we may hear more about this? I know willvarfar browses HN.


Vaporware does tend to be pretty bug-free.


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."


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?


> What part of the paper do you take issue with?

There exists no Mill CPU - just software models of it at best.


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?


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.


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


Nope, just whitepapers, presentations, and patents.


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


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: