By my understanding, the Meltdown and Spectre attacks both exploit the fact that some modern processor, when given something like:
if (x < arr1[y])
z = arr2[arr3[x]*256];
may sometimes fetch the value of arr2[arr3[x] * 256]
before they have determined whether x
is less than arr1[y]
, and may do this without regard for whether code has adequate permission to access arr3[x]
. The portion in italics is the sine qua non of the vulnerability: if the processor were to only fetch arr2[arr3[x] * 256]
in cases where the access to arr3[x]
was permissible, it would be impossible to exploit an to arr2[___ * 256]
using illegitimately-fetched arr3[x]
values because there wouldn't be any.
It makes sense that even if arr3[x]
is invalid, the processor can't trap unless or until it determines that x
is less than arr1[y]
. What I fail to understand is why a speculative fetch from an invalid address shouldn't cause the CPU to abandon the current speculative execution path? I would think that in almost every realistic scenario one of two things would happen:
The branch prediction that led to speculative execution turns out to be wrong, in which case any work that might be done with the speculatively-fetched value will need to be discarded.
The branch prediction that led to speculative execution turns out to be correct, in which case execution should trap at the invalid access, and work that might be done with the speculatively-fetched value (before executing the trap) will need to be discarded.
Is there any realistic scenario in which speculative work that follows a speculative fetch from an illegitimate address could turn out to be useful? If not, what advantage is there to allowing speculative execution to continue past such fetches? If an invalid fetch will make the CPU abandon the current line of speculative execution, that would avoid the need to keep track of speculative pending traps.