On 5 Jan, Ronald F. Guilmette wrote: > > In message > <sn1pr0501mb2125b36067cd93a5b95ac74dce...@sn1pr0501mb2125.namprd05.prod.out > look.com>, Andrew Duane <[email protected]> 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. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"
