[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Oct 2016 10:50:39 +0200
From: Pavel Machek <pavel@....cz>
To: Ingo Molnar <mingo@...nel.org>
Cc: Kees Cook <keescook@...omium.org>,
Peter Zijlstra <peterz@...radead.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
kernel list <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: rowhammer protection [was Re: Getting interrupt every million
cache misses]
On Fri 2016-10-28 09:07:01, Ingo Molnar wrote:
>
> * Pavel Machek <pavel@....cz> wrote:
>
> > +static void rh_overflow(struct perf_event *event, struct perf_sample_data *data, struct pt_regs *regs)
> > +{
> > + u64 *ts = this_cpu_ptr(&rh_timestamp); /* this is NMI context */
> > + u64 now = ktime_get_mono_fast_ns();
> > + s64 delta = now - *ts;
> > +
> > + *ts = now;
> > +
> > + /* FIXME msec per usec, reverse logic? */
> > + if (delta < 64 * NSEC_PER_MSEC)
> > + mdelay(56);
> > +}
>
> I'd suggest making the absolute delay sysctl tunable, because 'wait 56 msecs' is
> very magic, and do we know it 100% that 56 msecs is what is needed
> everywhere?
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 :-).
Thanks and best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
