Date: Tue, 10 Mar 2015 00:00:24 +0100 From: Willem Jan Withagen <wjw@digiware.nl> To: Bakul Shah <bakul@bitblocks.com>, Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-security@FreeBSD.org, Dmitry Morozovsky <marck@rinet.ru> Subject: Re: DRAM Rowhammer exploits Message-ID: <54FE2608.2080202@digiware.nl> 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 09/03/2015 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. ECC does not only correct bit errors, it also allows one the detect them. Perhaps a good reason to start watching the reports about them.. And how many bit do I need to change to actually do something usefull? > 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? That was my suggestion 1. Up the refresh frequency. Might require the manufacturer, but could very well be done by the kernel if it knew how,what,where to write this. > 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!] Isn't this what the RAM chip info tells us? And RAM does not move around in the physical address space. So creating a mapping where virtual = physical (perhaps even offsetted into an empty block in the vast 2^64 bits address space) would allow the refresh tread to do its work. But creating that mapping while running in kernelmode could be not so easy. --WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54FE2608.2080202>