5 ms·

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

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

cwzwarich 9y ago
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?
- hduty 9y ago
  seriously? Mill is/will do speculation before perms? And here I thought turfs were the elegant answer to this nightmare.
  - cwzwarich 9y ago
    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/ https://millcomputing.com/docs/metadata/ [2] https://millcomputing.com/docs/inter-process-communication/ https://millcomputing.com/docs/inter-process-communication/
    - willvarfar 9y ago
      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.
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?

cwzwarich 9y ago

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?

hduty 9y ago
seriously? Mill is/will do speculation before perms? And here I thought turfs were the elegant answer to this nightmare.
- cwzwarich 9y ago
  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/ https://millcomputing.com/docs/metadata/ [2] https://millcomputing.com/docs/inter-process-communication/ https://millcomputing.com/docs/inter-process-communication/
  - willvarfar 9y ago
    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.

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?