[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161028093547.GA9291@gmail.com>
Date: Fri, 28 Oct 2016 11:35:47 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Vegard Nossum <vegard.nossum@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Pavel Machek <pavel@....cz>,
Kees Cook <keescook@...omium.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]
* Vegard Nossum <vegard.nossum@...il.com> wrote:
> Would it make sense to sample the counter on context switch, do some
> accounting on a per-task cache miss counter, and slow down just the
> single task(s) with a too high cache miss rate? That way there's no
> global slowdown (which I assume would be the case here). The task's
> slice of CPU would have to be taken into account because otherwise you
> could have multiple cooperating tasks that each escape the limit but
> taken together go above it.
Attackers could work this around by splitting the rowhammer workload between
multiple threads/processes.
I.e. the problem is that the risk may come from any 'unprivileged user-space
code', where the rowhammer workload might be spread over multiple threads,
processes or even users.
Thanks,
Ingo
Powered by blists - more mailing lists