From owner-freebsd-security@freebsd.org Sat Jan 6 00:50:21 2018 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F8E1EAAD65 for ; Sat, 6 Jan 2018 00:50:21 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 50C3468B98 for ; Sat, 6 Jan 2018 00:50:21 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w060oYtD027372 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 6 Jan 2018 00:50:36 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w060Y38q017108 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jan 2018 16:50:12 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Fri, 5 Jan 2018 16:50:12 -0800 (PST) From: Don Lewis Subject: Re: Intel hardware bug To: "Ronald F. Guilmette" cc: Freebsd Security In-Reply-To: <5241.1515183470@segfault.tristatelogic.com> Message-ID: References: <5241.1515183470@segfault.tristatelogic.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 00:50:21 -0000 On 5 Jan, Ronald F. Guilmette wrote: > > In message look.com>, Andrew Duane 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.