From owner-freebsd-security@FreeBSD.ORG Tue Mar 10 16:23:32 2015 Return-Path: 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 ECCD0A23 for ; Tue, 10 Mar 2015 16:23:32 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63DB283B for ; Tue, 10 Mar 2015 16:23:31 +0000 (UTC) Received: from [192.168.0.143] ([95.91.226.153]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MIiHs-1YTA1B3epc-002GwB for ; Tue, 10 Mar 2015 17:23:29 +0100 Message-ID: <54FF1A81.4090706@gmx.de> Date: Tue, 10 Mar 2015 17:23:29 +0100 From: "lokadamus@gmx.de" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: DRAM Rowhammer exploits References: <91440.1425930724@critter.freebsd.dk> <20150309202308.64DFBB82A@mail.bitblocks.com> <70815.1425933979@critter.freebsd.dk> <20150309213702.B07A6B827@mail.bitblocks.com> In-Reply-To: <20150309213702.B07A6B827@mail.bitblocks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qQ7FEIvpZzz4LJl0Qjl07v/V8iBO788ScjeU2G+10cEJdz9RA35 4OVaiik9AXR+468KBNGLM2SYgdKjLOnLH9YNBet6oLCxLjIHBaOA7yLgGzXwf6LB/nm6zUf W9pgehuzr4b7CWurlVb0LZJEF7eEpLOGcFniCqi+PunD9VSIMgD3ftcma9OvnS+MC1n74jT k5d9jMCQ+Ju/FnZwrvV6w== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:23:33 -0000 On 03/09/15 22:37, Bakul Shah wrote: > On Mon, 09 Mar 2015 20:46:19 -0000 "Poul-Henning Kamp" > wrote: >> -------- In message >> <20150309202308.64DFBB82A@mail.bitblocks.com>, Bakul Shah >> writes: >>> On Mon, 09 Mar 2015 19:52:04 -0000 "Poul-Henning Kamp" >>> >> 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 > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security To > unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" > A stupid way is to make hash over physical address space. But how much time will it cost to make it, check and write a new value? And when should it control the memory? After each read? Then only small blocks can be controlled.