Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1759764AbcJ1Jxg (ORCPT <rfc822;w@1wt.eu>);
        Fri, 28 Oct 2016 05:53:36 -0400
Received: from foss.arm.com ([217.140.101.70]:55126 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1754961AbcJ1Jxf (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 28 Oct 2016 05:53:35 -0400
Date: Fri, 28 Oct 2016 10:53:01 +0100
From: Mark Rutland <mark.rutland@arm.com>
To: kernel-hardening@lists.openwall.com
Cc: Vegard Nossum <vegard.nossum@gmail.com>,
        Peter Zijlstra <peterz@infradead.org>, Pavel Machek <pavel@ucw.cz>,
        Kees Cook <keescook@chromium.org>,
        Arnaldo Carvalho de Melo <acme@redhat.com>,
        kernel list <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>
Subject: Re: [kernel-hardening] Re: rowhammer protection [was Re: Getting
 interrupt every million cache misses]
Message-ID: <20161028095301.GB5806@leverpostej>
References: <20161027082801.GE3568@worktop.programming.kicks-ass.net>
 <20161027091104.GB19469@amd>
 <20161027093334.GK3102@twins.programming.kicks-ass.net>
 <CAGXu5jL=xzyPRQgOp5ON2+X0=5z4-jg4NyFCrTSrRPm5puOm0Q@mail.gmail.com>
 <20161027212747.GA18147@amd>
 <20161028070701.GA11376@gmail.com>
 <20161028085039.GA15032@amd>
 <20161028090423.GY3102@twins.programming.kicks-ass.net>
 <CAOMGZ=HQxkFYhHuF0mDVcwO7m4z34e_PKb6jHGVC3Jwc-mhfXQ@mail.gmail.com>
 <20161028093547.GA9291@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161028093547.GA9291@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 839
Lines: 22

On Fri, Oct 28, 2016 at 11:35:47AM +0200, Ingo Molnar wrote:
> 
> * Vegard Nossum <vegard.nossum@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.

With the proposed approach, they could split across multiple CPUs
instead, no?

... or was that covered in a prior thread?

Thanks,
Mark.