Linux-mm Archive on
 help / color / Atom feed
From: Andy Lutomirski <>
To: Mark Seaborn <>
Cc: Pavel Machek <>,
	"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, 16 Mar 2015 18:21:44 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn <> wrote:
> On 16 March 2015 at 14:11, Pavel Machek <> wrote:
>> On Mon 2015-03-09 23:11:12, Kirill A. Shutemov wrote:
>> > From: "Kirill A. Shutemov" <>
>> >
>> > As pointed by recent post[1] on exploiting DRAM physical imperfection,
>> > /proc/PID/pagemap exposes sensitive information which can be used to do
>> > attacks.
>> >
>> > This is RFC patch which disallow anybody without CAP_SYS_ADMIN to read
>> > the pagemap.
>> >
>> > Any comments?
>> >
>> > [1]
>> Note that this kind of attack still works without pagemap, it just
>> takes longer. Actually the first demo program is not using pagemap.
> That depends on the machine -- it depends on how bad the machine's
> DRAM is, and whether the machine has the 2x refresh rate mitigation
> enabled.
> Machines with less-bad DRAM or with a 2x refresh rate might still be
> vulnerable to rowhammer, but only if the attacker has access to huge
> pages or to /proc/PID/pagemap.
> /proc/PID/pagemap also gives an attacker the ability to scan for bad
> DRAM locations, save a list of their addresses, and exploit them in
> the future.
> Given that, I think it would still be worthwhile to disable /proc/PID/pagemap.

Having slept on this further, I think that unprivileged pagemap access
is awful and we should disable it with no option to re-enable.  If we
absolutely must, we could allow programs to read all zeros or to read
addresses that are severely scrambled (e.g. ECB-encrypted by a key
generated once per open of pagemap).

Pagemap is awful because:

 - Rowhammer.

 - It exposes internals that users have no business knowing.

 - It could easily leak direct-map addresses, and there's a nice paper
detailing a SMAP bypass using that technique.

Can we just try getting rid of it except with global CAP_SYS_ADMIN.

(Hmm.  Rowhammer attacks targeting SMRAM could be interesting.)

>> Can we do anything about that? Disabling cache flushes from userland
>> should make it no longer exploitable.
> Unfortunately there's no way to disable userland code's use of
> CLFLUSH, as far as I know.
> Maybe Intel or AMD could disable CLFLUSH via a microcode update, but
> they have not said whether that would be possible.

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.


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 [this message]
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

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 \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \

* 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