Hi! > > I agree this needs to be tunable (and with the other suggestions). But > > this is actually not the most important tunable: the detection > > threshold (rh_attr.sample_period) should be way more important. > > > > And yes, this will all need to be tunable, somehow. But lets verify > > that this works, first :-). > > Yeah. > > Btw., a 56 NMI delay is pretty brutal in terms of latencies - it might > result in a smoother system to detect 100,000 cache misses and do a > ~5.6 msecs delay instead? > > (Assuming the shorter threshold does not trigger too often, of > course.)
Yeah, it is brutal workaround for a nasty bug. Slowdown depends on maximum
utilization:
+/*
+ * Maximum permitted utilization of DRAM. Setting this to f will mean that
+ * when more than 1/f of maximum cache-miss performance is used, delay will
+ * be inserted, and will have similar effect on rowhammer as refreshing memory
+ * f times more often.
+ *
+ * Setting this to 8 should prevent the rowhammer attack.
+ */
+ int dram_max_utilization_factor = 8;
| | no prot. | fact. 1 | fact. 2 | fact. 8 |
| linux-n900$ time ./mkit | 1m35 | 1m47 | 2m07 | 6m37 |
| rowhammer-test (for 43200000) | 2.86 | 9.75 | 16.7307 | 59.3738 |
(With factor 1 and 2 cpu attacker, we don't guarantee any protection.)
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
