From owner-freebsd-security@freebsd.org  Fri Jan  5 08:33:20 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 32D55EBD144
 for <freebsd-security@mailman.ysv.freebsd.org>;
 Fri,  5 Jan 2018 08:33:20 +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 1CA267DD18
 for <freebsd-security@freebsd.org>; Fri,  5 Jan 2018 08:33:19 +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 F3E183ACDA
 for <freebsd-security@freebsd.org>; Fri,  5 Jan 2018 00:33:12 -0800 (PST)
From: "Ronald F. Guilmette" <rfg@tristatelogic.com>
To: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>
Subject: Re: Intel hardware bug
In-Reply-To: <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net>
Date: Fri, 05 Jan 2018 00:33:12 -0800
Message-ID: <2594.1515141192@segfault.tristatelogic.com>
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: Fri, 05 Jan 2018 08:33:20 -0000


In message <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net>, 
Eric McCorkle <eric@metricspace.net> 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.


I must say, that's one hell of a round-about way to read just one bit that
you wern't supposed to have access to.  But of course, that doesn't really
matter if you are an attacker.

If the above steps can be repeated, programatically, ad infinitum, to read
bits from "protected" memory... and I see no reason why they can't be...
then yea, this bug is every bit as bad as the media is making it out to be,
and maybe even worse.

All your secrets are belong to us!

Time to invest in abacuses... or is that abacai?


Regards,
rfg