linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Gruss <daniel@gruss.cc>
To: "kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>
Cc: Pavel Machek <pavel@ucw.cz>, Mark Rutland <mark.rutland@arm.com>,
	Kees Cook <keescook@chromium.org>,
	Peter Zijlstra <peterz@infradead.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: Re: [kernel-hardening] rowhammer protection [was Re: Getting interrupt every million cache misses]
Date: Sat, 29 Oct 2016 15:06:02 +0200	[thread overview]
Message-ID: <d2f7dc1d-12ab-de12-cf73-7565fc27f5f7@gruss.cc> (raw)
In-Reply-To: <20161028172710.GA10309@amd>

I think that this idea to mitigate Rowhammer is not a good approach.

I wrote Rowhammer.js (we published a paper on that) and I had the first 
reproducible bit flips on DDR4 at both, increased and default refresh 
rates (published in our DRAMA paper).

We have researched the number of cache misses induced from different 
applications in the past and there are many applications that cause more 
cache misses than Rowhammer (published in our Flush+Flush paper) they 
just cause them on different rows.
Slowing down a system surely works, but you could also, as a mitigation 
just make this CPU core run at the lowest possible frequency. That would 
likely be more effective than the solution you suggest.

Now, every Rowhammer attack exploits not only the DRAM effects but also 
the way the operating system organizes memory.

Some papers exploit page deduplication and disabling page deduplication 
should be the default also for other reasons, such as information 
disclosure attacks. If page deduplication is disabled, attacks like 
Dedup est Machina and Flip Feng Shui are inherently not possible anymore.

Most other attacks target page tables (the Google exploit, Rowhammer.js, 
Drammer). Now in Rowhammer.js we suggested a very simple fix, that is 
just an extension of what Linux already does.
Unless out of memory page tables and user pages are not placed in the 
same 2MB region. We suggested that this behavior should be more strict 
even in memory pressure situations. If the OS can only find a page table 
that resides in the same 2MB region as a user page, the request should 
fail instead and the process requesting it should go out of memory. More 
generally, the attack surface is gone if the OS never places a page 
table in proximity of less than 2MB to a user page.
That is a simple fix that does not cost any runtime performance. It 
mitigates all these scary attacks and won't even incur a memory cost in 
most situation.

  reply	other threads:[~2016-10-29 13:12 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-26 20:54 Getting interrupt every million cache misses Pavel Machek
2016-10-27  8:28 ` Peter Zijlstra
2016-10-27  8:46   ` Pavel Machek
2016-10-27  9:15     ` Peter Zijlstra
2016-10-27  9:11   ` Pavel Machek
2016-10-27  9:33     ` Peter Zijlstra
2016-10-27 20:40       ` Kees Cook
2016-10-27 21:27         ` rowhammer protection [was Re: Getting interrupt every million cache misses] Pavel Machek
2016-10-28  7:07           ` Ingo Molnar
2016-10-28  8:50             ` Pavel Machek
2016-10-28  8:59               ` Ingo Molnar
2016-10-28 11:55                 ` Pavel Machek
2016-10-28  9:04               ` Peter Zijlstra
2016-10-28  9:27                 ` Vegard Nossum
2016-10-28  9:35                   ` Ingo Molnar
2016-10-28  9:47                     ` Vegard Nossum
2016-10-28  9:53                     ` [kernel-hardening] " Mark Rutland
2016-10-28 11:27                 ` Pavel Machek
2016-10-28  9:51           ` [kernel-hardening] " Mark Rutland
2016-10-28 11:21             ` Pavel Machek
2016-10-28 14:05               ` Mark Rutland
2016-10-28 14:18                 ` Peter Zijlstra
2016-10-28 18:30                   ` Pavel Machek
2016-10-28 18:48                     ` Peter Zijlstra
2016-11-02 18:13                   ` Pavel Machek
2016-10-28 17:27                 ` Pavel Machek
2016-10-29 13:06                   ` Daniel Gruss [this message]
2016-10-29 19:42                     ` Pavel Machek
2016-10-29 20:05                       ` Daniel Gruss
2016-10-29 21:05                         ` Pavel Machek
2016-10-29 21:07                           ` Daniel Gruss
2016-10-29 21:45                             ` Pavel Machek
2016-10-29 21:49                               ` Daniel Gruss
2016-10-29 22:01                                 ` Pavel Machek
2016-10-29 22:02                                   ` Daniel Gruss
2016-10-31  8:27                 ` Pavel Machek
2016-10-31 14:47                   ` Mark Rutland
2016-10-31 21:13                     ` Pavel Machek
2016-10-31 22:09                       ` Mark Rutland
2016-11-01  6:33                   ` Ingo Molnar
2016-11-01  7:20                     ` Daniel Micay
2016-11-01  7:53                     ` Daniel Gruss
2016-11-01  8:10                     ` Pavel Machek
2016-11-01  8:13                       ` Daniel Gruss

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d2f7dc1d-12ab-de12-cf73-7565fc27f5f7@gruss.cc \
    --to=daniel@gruss.cc \
    --cc=acme@redhat.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).