Intel hardware bug

[Don Lewis]

On  5 Jan, Ronald F. Guilmette wrote:
> 
> In message <SN1PR0501MB2125B36067CD93A5B95AC74DCE1C0 at SN1PR0501MB2125.namprd05.prod.out
> look.com>, Andrew Duane <aduane at juniper.net> wrote:
> 
>>I wouldn't think Javascript would have the accurate timing required to leve=
>>rage this attack, but I don't really know enough about the language.
> 
> This brings up something I have been wondering about, although my guess is
> that much greater minds than mine have already considered this possible
> mitigation...
> 
> If the meltdown or spectre (or both) attacks are based on careful analysis
> of timing information, following a memory fault, then why just just introduce
> a very tiny delay, of randomized duration, in the relevant kernel fault handler,
> following each such fault?

It's not the fault timing that matters.  The time that matters is the
difference in access time between a cache hit and a cache miss.  Whether
or not you get a cache hit vs. a cache miss is dependent on whether the
speculative execution filled that particular cache line, and that
depends on the value of the data that the exploit code is trying to
exfiltrate.  Since the code is being executed speculatively, a fault
only halts the speculative execution at that point and doesn't actually
result in a call to the fault handler because the CPU eventually figures
out that that execution path would not be taken afterall due to some
earlier condition that it eventually resolves.  That tosses all of the
CPU state associated with the speculative execution path, but the cache
state remains as a leftover side effect.