From owner-freebsd-security@freebsd.org Thu Jan 4 17:03:34 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 EA9E1EA59A1 for ; Thu, 4 Jan 2018 17:03:34 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id C075F73D9C for ; Thu, 4 Jan 2018 17:03:34 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [192.168.43.57] (mobile-166-171-187-140.mycingular.net [166.171.187.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id CE50E85D1; Thu, 4 Jan 2018 17:03:33 +0000 (UTC) Subject: Re: Intel hardware bug To: Brett Glass , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= , Erich Dollansky Cc: "freebsd-security@freebsd.org" , "Ronald F. Guilmette" References: <02563ce4-437c-ab96-54bb-a8b591900ba0@FreeBSD.org> <19876.1515025752@segfault.tristatelogic.com> <20180104132807.266fe46c.freebsd.ed.lists@sumeritec.com> <86vaghu0ps.fsf@desk.des.no> <201801041552.IAA17267@mail.lariat.net> <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net> <201801041621.JAA17566@mail.lariat.net> From: Eric McCorkle Message-ID: Date: Thu, 4 Jan 2018 12:03:32 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <201801041621.JAA17566@mail.lariat.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Thu, 04 Jan 2018 17:03:35 -0000 On 01/04/2018 11:21, Brett Glass wrote: > At 09:03 AM 1/4/2018, Eric McCorkle wrote: > >> The attack looks like this: >> >> 1) Fetch kernel/other process memory, which eventually faults >> 2) Do a bit-shift/mask operation to pluck out one bit of the fetched >> value.  This gets executed speculatively on the fetched value in (1). >> 3) Execute fetches of two different addresses depending on some bit in >> the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1).  This >> also gets executed speculatively despite the fact that (1) ends up >> faulting. >> 4) Recover from fault in (1) >> 5) Measure performance of accesses to the two addresses to determine >> which one is cached. > > Hmmmm. The obvious way to combat this would be to make this class of fault > fatal rather than allowing recovery to occur. Of course, this would > reveal errors > in sloppy code, which some developers would not like. (I recall how much > some > folks squawked back in the olden days, when segmentation faults - remember > segments? - revealed bugs in their code. I, personally, liked segmentation > because I was a perfectionist.... I wanted my code to crash dramatically if > there was an error so I could fix it.) > That breaks the entire way that page faults and virtual memory works, though. You could block meltdown, I suppose, by making the entire kernel address space absolutely forbidden under penalty of an uncatchable signal. This won't stop spectre (same attack against another process' pages), or a similar attack within the same address space (say, to break out of some kind of intra-process isolation).