DRAM Rowhammer exploits

[lokadamus at gmx.de]

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