Date: Tue, 10 Mar 2015 17:23:29 +0100 From: "lokadamus@gmx.de" <lokadamus@gmx.de> To: freebsd-security@freebsd.org Subject: Re: DRAM Rowhammer exploits Message-ID: <54FF1A81.4090706@gmx.de> In-Reply-To: <20150309213702.B07A6B827@mail.bitblocks.com> 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> <20150309213702.B07A6B827@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/09/15 22:37, Bakul Shah wrote: > 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 > > _______________________________________________ > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54FF1A81.4090706>