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