Reply To: Mill vs. Spectre: Performance and Security

Hi,

I was following Mill developments for few years, and I just watched this video about Spectre vs Mill today, and I still have an issue. Yes, Mill is not speculative in hardware, but as you said, compiler will do a speculation in software by reordering loads to get best performance and hide stalls.

So C code like:

int foo(int x) {
  if (x < 100) {
    return 0;
  }
  return A2[A1[x] * 64];
}

will produce op codes like this:

compare x, 100
return if false
load A1[x] to k
shift k
load A2[shifted k] to r
return r

any optimizing compiler will convert this into:

load A1[x] to k, delay=2
compare x, 100
return if false
shift k
load A2[shifted k] to r
return r

or even more aggressively into

load A1[x] to k, delay=0
shift k
load A2[shifted k] to r, delay=2
compare x, 100
return if false
return r

semantic is the same, even if loads accesses invalid memory, and produce NaR, and ultimate a fault in ‘return r’.

So, the loads will still pollute the cache, and a timing attack can be performed. And I do not see how Mill is any safer, because code will still do speculation due to compiler.

To prevent speculation by compiler, you will need to either tell compiler not to do so (loosing some performance), or annotate specific fragments of code as critical and not be speculated by compiler, which is as error prone as mitigation and barriers you would put manually on OoO speculative machines.