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.

Spot 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 ;)

It 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?

seriously? Mill is/will do speculation before perms? And here I thought turfs were the elegant answer to this nightmare.

See 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/ [2] https://millcomputing.com/docs/inter-process-communication/

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

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