On 28 October 2016 at 11:35, Ingo Molnar <mi...@kernel.org> wrote: > > * Vegard Nossum <vegard.nos...@gmail.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.
That's why I emphasised the number of misses per CPU slice rather than just the total number of misses. I assumed there must be at least one task continuously hammering memory for a successful attack, in which case it should be observable with as little as 1 slice of CPU (however long that is), no? Vegard