From owner-freebsd-security@freebsd.org Fri Jan 5 20:17:53 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 181CEEBE175 for ; Fri, 5 Jan 2018 20:17:53 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 03E887C1F7 for ; Fri, 5 Jan 2018 20:17:52 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id D42623AEF2 for ; Fri, 5 Jan 2018 12:17:50 -0800 (PST) From: "Ronald F. Guilmette" To: Freebsd Security Subject: Re: Intel hardware bug In-Reply-To: Date: Fri, 05 Jan 2018 12:17:50 -0800 Message-ID: <5241.1515183470@segfault.tristatelogic.com> 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: Fri, 05 Jan 2018 20:17:53 -0000 In message , 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? (Since nothing I've read is talking about this, I am guessing that this would be an even bigger loser, performance-wise, than the mitigations that have been developed so far.) Regards, rfg