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"
