From owner-freebsd-security@freebsd.org  Thu Jan  4 16:22:39 2018
Return-Path: <owner-freebsd-security@freebsd.org>
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 CE33DEC1329
 for <freebsd-security@mailman.ysv.freebsd.org>;
 Thu,  4 Jan 2018 16:22:39 +0000 (UTC)
 (envelope-from brett@lariat.org)
Received: from mail.lariat.net (mail.lariat.net [66.62.230.51])
 by mx1.freebsd.org (Postfix) with ESMTP id 9A76471EB5
 for <freebsd-security@freebsd.org>; Thu,  4 Jan 2018 16:22:39 +0000 (UTC)
 (envelope-from brett@lariat.org)
Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@localhost
 [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id JAA17566;
 Thu, 4 Jan 2018 09:21:50 -0700 (MST)
Message-Id: <201801041621.JAA17566@mail.lariat.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 04 Jan 2018 09:21:24 -0700
To: Eric McCorkle <eric@metricspace.net>, Dag-Erling Smørgrav <des@des.no>,
        Erich Dollansky <freebsd.ed.lists@sumeritec.com>
From: Brett Glass <brett@lariat.org>
Subject: Re: Intel hardware bug
Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>,
 "Ronald F. Guilmette" <rfg@tristatelogic.com>
In-Reply-To: <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-BeenThere: freebsd-security@freebsd.org
X-Mailman-Version: 2.1.25
Precedence: list
List-Id: "Security issues \[members-only posting\]"
 <freebsd-security.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-security>, 
 <mailto:freebsd-security-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security/>
List-Post: <mailto:freebsd-security@freebsd.org>
List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-security>, 
 <mailto:freebsd-security-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jan 2018 16:22:39 -0000

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.)

--Brett Glass