
Mill CPU is Immune to Spectre, Meltdown [pdf] - maxharris
https://millcomputing.com/blog/wp-content/uploads/2018/01/Spectre.03.pdf
======
kbob
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
#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
> 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.

------
remy_luisant
Vaporware does tend to be pretty bug-free.

~~~
maxharris
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
> What part of the paper do you take issue with?

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

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

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

~~~
ac29
Nope, just whitepapers, presentations, and patents.

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

~~~
sli
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)

