From owner-freebsd-security@FreeBSD.ORG  Mon Mar  9 21:37:03 2015
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Delivered-To: freebsd-security@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id AD02F18E
 for <freebsd-security@FreeBSD.org>; Mon,  9 Mar 2015 21:37:03 +0000 (UTC)
Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8])
 by mx1.freebsd.org (Postfix) with ESMTP id 8EBAB176
 for <freebsd-security@FreeBSD.org>; Mon,  9 Mar 2015 21:37:03 +0000 (UTC)
Received: from bitblocks.com (localhost [127.0.0.1])
 by mail.bitblocks.com (Postfix) with ESMTP id B07A6B827;
 Mon,  9 Mar 2015 14:37:02 -0700 (PDT)
To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
Subject: Re: DRAM Rowhammer exploits
In-reply-to: Your message of "Mon, 09 Mar 2015 20:46:19 -0000."
 <70815.1425933979@critter.freebsd.dk>
References: <alpine.BSF.2.00.1503092248580.38285@woozle.rinet.ru>
 <91440.1425930724@critter.freebsd.dk>
 <20150309202308.64DFBB82A@mail.bitblocks.com>
 <70815.1425933979@critter.freebsd.dk>
Comments: In-reply-to "Poul-Henning Kamp" <phk@phk.freebsd.dk>
 message dated "Mon, 09 Mar 2015 20:46:19 -0000."
Date: Mon, 09 Mar 2015 14:37:02 -0700
From: Bakul Shah <bakul@bitblocks.com>
Message-Id: <20150309213702.B07A6B827@mail.bitblocks.com>
Cc: freebsd-security@FreeBSD.org, Dmitry Morozovsky <marck@rinet.ru>
X-BeenThere: freebsd-security@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: "Security issues \[members-only posting\]"
 <freebsd-security.freebsd.org>
List-Unsubscribe: <http://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: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>, 
 <mailto:freebsd-security-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2015 21:37:03 -0000

On Mon, 09 Mar 2015 20:46:19 -0000 "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:
> --------
> In message <20150309202308.64DFBB82A@mail.bitblocks.com>, Bakul Shah writes:
> >On Mon, 09 Mar 2015 19:52:04 -0000 "Poul-Henning Kamp" <phk@phk.freebsd.dk> 
> wrote:
> 
> >Hopefully ECC memory protects against such exploits (at least
> >makes them a lot less vulnerable).
> 
> ECC only makes it harder, it doesn't make it impossible.

According to the small sample in the paper below, the
incidence of 3 bit errors is about 4000 times or more lower
than single bit errors.  These are the errors that may not
even get detected by ECC. So not impossible but much better.

http://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_isca14.pdf

It also proposes a few solutions. It seems to indicate that
reducing refresh time by a factor of 7 (over 64ms) removes
such errors. Hopefully this can be done via a firmware
upgrade?

I don't know if the physical page pool for kernel data can be
isolated enough from user data to avoid this. [Probably not.
Likely there is no standard way to do map a phys addr to a
specific chip/row and diff. mfrs may use diff geometries.
Though, perhaps this same phenomenon can be used to infer chip
geometry!]

Also see:
http://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_kim_talk_isca14.pdf