On 09/03/2015 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.
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 _______________________________________________ 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"
