On 03/09/15 22:37, Bakul Shah wrote: > On Mon, 09 Mar 2015 20:46:19 -0000 "Poul-Henning Kamp" > <p...@phk.freebsd.dk> wrote: >> -------- In message >> <20150309202308.64dfbb...@mail.bitblocks.com>, Bakul Shah >> writes: >>> On Mon, 09 Mar 2015 19:52:04 -0000 "Poul-Henning Kamp" >>> <p...@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-unsubscr...@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.
_______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
