Mill CPU is Immune to Spectre, Meltdown [pdf]
millcomputing.com
millcomputing.com
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.
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.
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?
There exists no Mill CPU - just software models of it at best.
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.