Date: Fri, 5 Jan 2018 16:50:12 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: Freebsd Security <freebsd-security@freebsd.org> Subject: Re: Intel hardware bug Message-ID: <tkrat.051f20d9d14ac044@FreeBSD.org> In-Reply-To: <5241.1515183470@segfault.tristatelogic.com> References: <SN1PR0501MB2125B36067CD93A5B95AC74DCE1C0@SN1PR0501MB2125.namprd05.prod.outlook.com> <5241.1515183470@segfault.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 Jan, Ronald F. Guilmette wrote: > > In message <SN1PR0501MB2125B36067CD93A5B95AC74DCE1C0@SN1PR0501MB2125.namprd05.prod.out > look.com>, Andrew Duane <aduane@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?tkrat.051f20d9d14ac044>