3 ms·
I'm curious, because I think the Mill as described in the talks is vulnerable to a variant of Spectre. If you have a sequence of code like this: if (index
by cwzwarich 9y ago
I'm curious, because I think the Mill as described in the talks is vulnerable to a variant of Spectre. If you have a sequence of code like this:
if (index < bounds) {
index2 = array1[index];
... array2[index2];
}
If the compiler speculates both array accesses above the bounds check, then the first one can still succeed (i.e. not produce a NaR) while accessing attacker-controlled memory for the value of index2.
You could obviously fix this by never generating code that does double speculation, but you could also do that by modifying a conventional OoO microarchitecture.
- willvarfar 9y agoSpot on! This variant of Spectre would be software bug not a hardware bug on the mill. Our specialiser had to be fixed to not produce code with this flaw. And so we wrote a light paper on it, and perhaps a talk etc ;)
- cwzwarich 9y agoIt seems that Mill's combination of a single address space and speculation-before-permissions-checks is still quite vulnerable to an ASLR leak. Have you made any changes to mitigate this, or do you just consider address space layout leaks acceptable behavior?
- hduty 9y agoseriously? Mill is/will do speculation before perms? And here I thought turfs were the elegant answer to this nightmare.
- cwzwarich 9y agoSee slide 72 of the metadata talk[1] and slide 51 of the IPC talk[2], which indicate that it does speculation before permissions checking. Since turf permissions operate on the granularity of an arbitrary address range (rather than a page like traditional MMUs), the permissions cache (what the Mill calls a PLB) has a worse latency/power tradeoff than a traditional TLB. The Mill takes advantage of its single address space and reduces some of this hit by doing permissions checks in parallel with the access. [1] https://millcomputing.com/docs/metadata/ https://millcomputing.com/docs/metadata/ [2] https://millcomputing.com/docs/inter-process-communication/ https://millcomputing.com/docs/inter-process-communication/
- willvarfar 9y agoThank you for watching the talks! :D Luckily its not quite as you interpreted: The L1$D is accessed in parallel with the PLB. Both at top-level caches - one for data, one for protection. If there is a PLB miss we have no cache-visible side-effects until the protection has been resolved. The paper we're preparing will cover this in detail, because as you can see, the talks are a bit light on exactly what happens in what order when here.
- gpderetta 9y ago>Our specialiser had to be fixed to not produce code with this flaw. Isn't prefetching/load-hoisting pretty much required to get any sort of performance out of an in-order VLIW-like machine?