Linux-mm Archive on
 help / color / Atom feed
From: Vlastimil Babka <>
To: Pavel Machek <>
Cc: Andy Lutomirski <>,
	Mark Seaborn <>,
	"Kirill A. Shutemov" <>,
	"" <>,
	kernel list <>,
	Andrew Morton <>,
	Linus Torvalds <>,
	"Kirill A. Shutemov" <>,
	Pavel Emelyanov <>,
	Konstantin Khlebnikov <>
Subject: Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
Date: Mon, 23 Mar 2015 23:36:56 +0100
Message-ID: <> (raw)
In-Reply-To: <20150323212559.GF14779@amd>

On 23.3.2015 22:26, Pavel Machek wrote:
> On Thu 2015-03-19 13:51:02, Vlastimil Babka wrote:
>> On 03/17/2015 02:21 AM, Andy Lutomirski wrote:
>>> On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn <> wrote:
>>> The Intel people I asked last week weren't confident.  For one thing,
>>> I fully expect that rowhammer can be exploited using only reads and
>>> writes with some clever tricks involving cache associativity.  I don't
>>> think there are any fully-associative caches, although the cache
>>> replacement algorithm could make the attacks interesting.
>> I've been thinking the same. But maybe having to evict e.g. 16-way cache would
>> mean accessing 16x more lines which could reduce the frequency for a single line
>> below dangerous levels. Worth trying, though :)
> How many ways do recent CPU L1 caches have?

My i7 based desktop has 8-way L1, 8-way L2, 16-way L3. And it seems to be
alarmingly vulnerable to the double-sided rowhammer variant. But to reliably
miss L3 it seems I need at least 96 addresses colliding in L3, which are then
also in different dram rows. Which naturally reduces frequency for the target
pair of rows. I've been able so far to reduce/mask the overhead so that the
target rows are accessed with 11x lower frequency than with clflush. Which
doesn't seem enough to trigger bit flips. But maybe I can improve it further :)

To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to  For more info on Linux MM,
see: .
Don't email: <a href=mailto:""> </a>

      reply index

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-09 21:11 Kirill A. Shutemov
2015-03-09 21:20 ` Pavel Emelyanov
2015-03-09 22:09 ` Konstantin Khlebnikov
2015-03-10  0:11 ` Kees Cook
2015-03-10  0:19   ` Andy Lutomirski
2015-03-10  2:36     ` Dave Hansen
2015-03-16 21:11 ` Pavel Machek
2015-03-17  0:49   ` Mark Seaborn
2015-03-17  1:21     ` Andy Lutomirski
2015-03-17 11:16       ` rowhammer and pagemap (was Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace) Pavel Machek
2015-03-17 17:58         ` One Thousand Gnomes
2015-03-23 21:26           ` Pavel Machek
2015-03-19 12:51       ` [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace Vlastimil Babka
2015-03-23 21:26         ` Pavel Machek
2015-03-23 22:36           ` Vlastimil Babka [this message]

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-mm Archive on

Archives are clonable:
	git clone --mirror linux-mm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mm linux-mm/ \
	public-inbox-index linux-mm

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone