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.
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."
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.
14 comments
[ 2.8 ms ] story [ 50.9 ms ] threadCan 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.
https://wiki.haskell.org/Haskell_in_industry
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.