Reply To: Mill vs. Spectre: Performance and Security

Looking at this:
– traditional architectures respond to an invalid memory access (and some other invalid operations) by faulting.
– with OOO speculative execution, the fault can’t be issued until the speculation is resolved and we know whether the code needed to run.
– So speculatively executed code has security deferred and applied retroactively. Which would not be a problem except for side effects, like the cache.

The mill, in contrast, uses NARs to defer faulting as far as possible. We expect to be explicitly executing code with bad input, and then tossing the result based on a comparison performed in parallel. The invalid access is marked BEFORE the result can be used for any operation which might produce side effects. So the exfiltration step gets not a speculative value, but a very real NAR.

I’m thinking that a mostly traditional architecture could avoid Specter if it also used NAR tagging on invalid memory reads.

Going back to the example, what if A1[x] was a legal read for the program, but outside the range of the array A1? No fault or NAR would be generated. So the execution would have to be ordered to perform the range check before the lookup in A2 was performed. An easy enough check for the Mill specializer, not such an easy patch for existing OOO hardware.