LKML Archive on lore.kernel.org
 help / Atom feed
* [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
@ 2015-03-09 21:11 Kirill A. Shutemov
  2015-03-09 21:20 ` Pavel Emelyanov
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Kirill A. Shutemov @ 2015-03-09 21:11 UTC (permalink / raw)
  To: linux-mm, linux-kernel, Andrew Morton, Linus Torvalds
  Cc: Kirill A. Shutemov, Pavel Emelyanov, Konstantin Khlebnikov,
	Mark Seaborn, Andy Lutomirski

From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>

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] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Seaborn <mseaborn@chromium.org>
Cc: Andy Lutomirski <luto@amacapital.net>
---
 fs/proc/task_mmu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 246eae84b13b..b72b36e64286 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1322,6 +1322,9 @@ out:
 
 static int pagemap_open(struct inode *inode, struct file *file)
 {
+	/* do not disclose physical addresses: attack vector */
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
 	pr_warn_once("Bits 55-60 of /proc/PID/pagemap entries are about "
 			"to stop being page-shift some time soon. See the "
 			"linux/Documentation/vm/pagemap.txt for details.\n");
-- 
2.3.1


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
  2015-03-09 21:11 [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace Kirill A. Shutemov
@ 2015-03-09 21:20 ` Pavel Emelyanov
  2015-03-09 22:09 ` Konstantin Khlebnikov
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 15+ messages in thread
From: Pavel Emelyanov @ 2015-03-09 21:20 UTC (permalink / raw)
  To: Kirill A. Shutemov, linux-mm, linux-kernel, Andrew Morton,
	Linus Torvalds
  Cc: Kirill A. Shutemov, Konstantin Khlebnikov, Mark Seaborn, Andy Lutomirski

On 03/10/2015 12:11 AM, Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> 
> 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?

If I'm not mistaken, the pagemap file is used by some userspace that does 
working-set size analysis. But this thing only needs the flags (referenced
bit) from the PTE-s. Maybe it would be better not to lock this file completely,
but instead report the PFN part as zero?

Other than this, I don't mind :) Although we use this heavily in CRIU we
anyway work only with the CAP_SYS_ADMIN, so adding the new one doesn't hurt.

Thanks,
Pavel

> [1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
> 
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Cc: Pavel Emelyanov <xemul@parallels.com>
> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Mark Seaborn <mseaborn@chromium.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> ---
>  fs/proc/task_mmu.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 246eae84b13b..b72b36e64286 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1322,6 +1322,9 @@ out:
>  
>  static int pagemap_open(struct inode *inode, struct file *file)
>  {
> +	/* do not disclose physical addresses: attack vector */
> +	if (!capable(CAP_SYS_ADMIN))
> +		return -EPERM;
>  	pr_warn_once("Bits 55-60 of /proc/PID/pagemap entries are about "
>  			"to stop being page-shift some time soon. See the "
>  			"linux/Documentation/vm/pagemap.txt for details.\n");
> 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
  2015-03-09 21:11 [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace 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-16 21:11 ` Pavel Machek
  3 siblings, 0 replies; 15+ messages in thread
From: Konstantin Khlebnikov @ 2015-03-09 22:09 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: linux-mm, Linux Kernel Mailing List, Andrew Morton,
	Linus Torvalds, Kirill A. Shutemov, Pavel Emelyanov,
	Mark Seaborn, Andy Lutomirski

On Tue, Mar 10, 2015 at 12:11 AM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
> From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>
> 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] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Cc: Pavel Emelyanov <xemul@parallels.com>
> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Mark Seaborn <mseaborn@chromium.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> ---
>  fs/proc/task_mmu.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 246eae84b13b..b72b36e64286 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1322,6 +1322,9 @@ out:
>
>  static int pagemap_open(struct inode *inode, struct file *file)
>  {
> +       /* do not disclose physical addresses: attack vector */
> +       if (!capable(CAP_SYS_ADMIN))
> +               return -EPERM;

This interface is connected to /proc/kpagecount, /proc/kpageflags
and these files are readable only by root. So it's fine, but it's might
be better to change here file owner to root too.

>         pr_warn_once("Bits 55-60 of /proc/PID/pagemap entries are about "
>                         "to stop being page-shift some time soon. See the "
>                         "linux/Documentation/vm/pagemap.txt for details.\n");
> --
> 2.3.1
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
  2015-03-09 21:11 [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace 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-16 21:11 ` Pavel Machek
  3 siblings, 1 reply; 15+ messages in thread
From: Kees Cook @ 2015-03-10  0:11 UTC (permalink / raw)
  To: Kirill A. Shutemov, Dave Hansen, Eric W. Biederman
  Cc: Linux-MM, LKML, Andrew Morton, Linus Torvalds,
	Kirill A. Shutemov, Pavel Emelyanov, Konstantin Khlebnikov,
	Mark Seaborn, Andy Lutomirski

On Mon, Mar 9, 2015 at 2:11 PM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
> From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>
> 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?

I prefer Dave Hansen's approach:

http://www.spinics.net/lists/kernel/msg1941939.html

This gives finer grained control without globally dropping the ability
of a non-root process to examine pagemap details (which is the whole
point of the interface).

-Kees

>
> [1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Cc: Pavel Emelyanov <xemul@parallels.com>
> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Mark Seaborn <mseaborn@chromium.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> ---
>  fs/proc/task_mmu.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 246eae84b13b..b72b36e64286 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1322,6 +1322,9 @@ out:
>
>  static int pagemap_open(struct inode *inode, struct file *file)
>  {
> +       /* do not disclose physical addresses: attack vector */
> +       if (!capable(CAP_SYS_ADMIN))
> +               return -EPERM;
>         pr_warn_once("Bits 55-60 of /proc/PID/pagemap entries are about "
>                         "to stop being page-shift some time soon. See the "
>                         "linux/Documentation/vm/pagemap.txt for details.\n");
> --
> 2.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Kees Cook
Chrome OS Security

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
  2015-03-10  0:11 ` Kees Cook
@ 2015-03-10  0:19   ` Andy Lutomirski
  2015-03-10  2:36     ` Dave Hansen
  0 siblings, 1 reply; 15+ messages in thread
From: Andy Lutomirski @ 2015-03-10  0:19 UTC (permalink / raw)
  To: Kees Cook
  Cc: Kirill A. Shutemov, Dave Hansen, Eric W. Biederman, Linux-MM,
	LKML, Andrew Morton, Linus Torvalds, Kirill A. Shutemov,
	Pavel Emelyanov, Konstantin Khlebnikov, Mark Seaborn

On Mon, Mar 9, 2015 at 5:11 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Mar 9, 2015 at 2:11 PM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
>> From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>>
>> 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?
>
> I prefer Dave Hansen's approach:
>
> http://www.spinics.net/lists/kernel/msg1941939.html
>
> This gives finer grained control without globally dropping the ability
> of a non-root process to examine pagemap details (which is the whole
> point of the interface).

per-pidns like this is no good.  You shouldn't be able to create a
non-paranoid pidns if your parent is paranoid.

Also, at some point we need actual per-ns controls.  This mount option
stuff is hideous.

--Andy

>
> -Kees
>
>>
>> [1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
>>
>> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>> Cc: Pavel Emelyanov <xemul@parallels.com>
>> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Linus Torvalds <torvalds@linux-foundation.org>
>> Cc: Mark Seaborn <mseaborn@chromium.org>
>> Cc: Andy Lutomirski <luto@amacapital.net>
>> ---
>>  fs/proc/task_mmu.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>> index 246eae84b13b..b72b36e64286 100644
>> --- a/fs/proc/task_mmu.c
>> +++ b/fs/proc/task_mmu.c
>> @@ -1322,6 +1322,9 @@ out:
>>
>>  static int pagemap_open(struct inode *inode, struct file *file)
>>  {
>> +       /* do not disclose physical addresses: attack vector */
>> +       if (!capable(CAP_SYS_ADMIN))
>> +               return -EPERM;
>>         pr_warn_once("Bits 55-60 of /proc/PID/pagemap entries are about "
>>                         "to stop being page-shift some time soon. See the "
>>                         "linux/Documentation/vm/pagemap.txt for details.\n");
>> --
>> 2.3.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>
> --
> Kees Cook
> Chrome OS Security



-- 
Andy Lutomirski
AMA Capital Management, LLC

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
  2015-03-10  0:19   ` Andy Lutomirski
@ 2015-03-10  2:36     ` Dave Hansen
  0 siblings, 0 replies; 15+ messages in thread
From: Dave Hansen @ 2015-03-10  2:36 UTC (permalink / raw)
  To: Andy Lutomirski, Kees Cook
  Cc: Kirill A. Shutemov, Eric W. Biederman, Linux-MM, LKML,
	Andrew Morton, Linus Torvalds, Kirill A. Shutemov,
	Pavel Emelyanov, Konstantin Khlebnikov, Mark Seaborn

On 03/09/2015 05:19 PM, Andy Lutomirski wrote:
> per-pidns like this is no good.  You shouldn't be able to create a
> non-paranoid pidns if your parent is paranoid.

That sounds like a reasonable addition that shouldn't be hard to add.

> Also, at some point we need actual per-ns controls.  This mount option
> stuff is hideous.

So,

	per-pidns == bad
	per-ns == good

If the pid namespace is the wrong place, which namespace is the right place?



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
  2015-03-09 21:11 [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace Kirill A. Shutemov
                   ` (2 preceding siblings ...)
  2015-03-10  0:11 ` Kees Cook
@ 2015-03-16 21:11 ` Pavel Machek
  2015-03-17  0:49   ` Mark Seaborn
  3 siblings, 1 reply; 15+ messages in thread
From: Pavel Machek @ 2015-03-16 21:11 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: linux-mm, linux-kernel, Andrew Morton, Linus Torvalds,
	Kirill A. Shutemov, Pavel Emelyanov, Konstantin Khlebnikov,
	Mark Seaborn, Andy Lutomirski

On Mon 2015-03-09 23:11:12, Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> 
> 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]
http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

Note that this kind of attack still works without pagemap, it just
takes longer. Actually the first demo program is not using pagemap.

Can we do anything about that? Disabling cache flushes from userland
should make it no longer exploitable.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
  2015-03-16 21:11 ` Pavel Machek
@ 2015-03-17  0:49   ` Mark Seaborn
  2015-03-17  1:21     ` Andy Lutomirski
  0 siblings, 1 reply; 15+ messages in thread
From: Mark Seaborn @ 2015-03-17  0:49 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Kirill A. Shutemov, linux-mm, kernel list, Andrew Morton,
	Linus Torvalds, Kirill A. Shutemov, Pavel Emelyanov,
	Konstantin Khlebnikov, Andy Lutomirski

On 16 March 2015 at 14:11, Pavel Machek <pavel@ucw.cz> wrote:
> On Mon 2015-03-09 23:11:12, Kirill A. Shutemov wrote:
> > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> >
> > 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] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
>
> 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.


> 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.

Cheers,
Mark

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
  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-19 12:51       ` [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace Vlastimil Babka
  0 siblings, 2 replies; 15+ messages in thread
From: Andy Lutomirski @ 2015-03-17  1:21 UTC (permalink / raw)
  To: Mark Seaborn
  Cc: Pavel Machek, Kirill A. Shutemov, linux-mm, kernel list,
	Andrew Morton, Linus Torvalds, Kirill A. Shutemov,
	Pavel Emelyanov, Konstantin Khlebnikov

On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn <mseaborn@chromium.org> wrote:
> On 16 March 2015 at 14:11, Pavel Machek <pavel@ucw.cz> wrote:
>> On Mon 2015-03-09 23:11:12, Kirill A. Shutemov wrote:
>> > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>> >
>> > 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] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
>>
>> 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.

--Andy

^ permalink raw reply	[flat|nested] 15+ messages in thread

* rowhammer and pagemap (was Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace)
  2015-03-17  1:21     ` Andy Lutomirski
@ 2015-03-17 11:16       ` Pavel Machek
  2015-03-17 17:58         ` One Thousand Gnomes
  2015-03-19 12:51       ` [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace Vlastimil Babka
  1 sibling, 1 reply; 15+ messages in thread
From: Pavel Machek @ 2015-03-17 11:16 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Mark Seaborn, Kirill A. Shutemov, linux-mm, kernel list,
	Andrew Morton, Linus Torvalds, Kirill A. Shutemov,
	Pavel Emelyanov, Konstantin Khlebnikov



> > 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).

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

Do you have a pointer?

> 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.

We should definitely get Intel/AMD to disable CLFLUSH, then.

Because if it can be exploited using reads, it is _extremely_
important to know. As it probably means rowhammer can be exploited
using Javascript / Java... and affected machines are unsafe even
without remote users.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: rowhammer and pagemap (was Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace)
  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
  0 siblings, 1 reply; 15+ messages in thread
From: One Thousand Gnomes @ 2015-03-17 17:58 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Andy Lutomirski, Mark Seaborn, Kirill A. Shutemov, linux-mm,
	kernel list, Andrew Morton, Linus Torvalds, Kirill A. Shutemov,
	Pavel Emelyanov, Konstantin Khlebnikov

> > Can we just try getting rid of it except with global CAP_SYS_ADMIN.
> > 
> > (Hmm.  Rowhammer attacks targeting SMRAM could be interesting.)
> 

CAP_SYS_RAWIO is the protection for "can achieve anything". If you have
CAP_SYS_RAWIO you can attain any other capability, the reverse _should_
not be true.

> > 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.
> 
> We should definitely get Intel/AMD to disable CLFLUSH, then.

I doubt that would work, because you'd have to fix up all the faults from
userspace in things like graphics and video. Whether it is possible to
make the microcode do other accesses and delays I have no idea - but
that might also be quite horrible.

A serious system should be using ECC memory anyway. and on things like
shared boxes it is probably not a root compromise that is the worst case
scenario but subtle undetected corruption of someone elses data sets.

That's what ECC already exists to protect against whether its from flawed
memory and rowhammer or just a vindictive passing cosmic ray.

Alan



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
  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-19 12:51       ` Vlastimil Babka
  2015-03-23 21:26         ` Pavel Machek
  1 sibling, 1 reply; 15+ messages in thread
From: Vlastimil Babka @ 2015-03-19 12:51 UTC (permalink / raw)
  To: Andy Lutomirski, Mark Seaborn
  Cc: Pavel Machek, Kirill A. Shutemov, linux-mm, kernel list,
	Andrew Morton, Linus Torvalds, Kirill A. Shutemov,
	Pavel Emelyanov, Konstantin Khlebnikov

On 03/17/2015 02:21 AM, Andy Lutomirski wrote:
> On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn <mseaborn@chromium.org> wrote:
>> On 16 March 2015 at 14:11, Pavel Machek <pavel@ucw.cz> wrote:
>>
>>> 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.

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 :)

BTW, by using clever access patterns and measurement of access latencies one
could also possibly determine which cache lines alias/colide, without needing to
read pagemap. It would just take longer. Hugepages make that simpler as well.

I just hope we are not going to disable lots of stuff including clflush and e.g.
transparent hugepages just because some part of the currently sold hardware is
vulnerable...

Vlastimil

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
  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
  0 siblings, 1 reply; 15+ messages in thread
From: Pavel Machek @ 2015-03-23 21:26 UTC (permalink / raw)
  To: Vlastimil Babka
  Cc: Andy Lutomirski, Mark Seaborn, Kirill A. Shutemov, linux-mm,
	kernel list, Andrew Morton, Linus Torvalds, Kirill A. Shutemov,
	Pavel Emelyanov, Konstantin Khlebnikov

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 <mseaborn@chromium.org> wrote:
> >> On 16 March 2015 at 14:11, Pavel Machek <pavel@ucw.cz> wrote:
> >>
> >>> 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.
> 
> 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?

> BTW, by using clever access patterns and measurement of access latencies one
> could also possibly determine which cache lines alias/colide, without needing to
> read pagemap. It would just take longer. Hugepages make that simpler as well.
> 
> I just hope we are not going to disable lots of stuff including clflush and e.g.
> transparent hugepages just because some part of the currently sold hardware is
> vulnerable...

Well, "some part" seems to be > 50% of all machines without ECC, which
means > 50% notebooks.

If your machine is not affected, disabling clflush will not be
neccessary. But... I'd still like separate users on my machines to be
separated (I use separate acount for browsing with Flash), and Android
actually relies on that.

And if it is exploitable without clflush, that's _bad_, because it
means you can probably exploit it using Java/JavaScript from web
browser.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: rowhammer and pagemap (was Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace)
  2015-03-17 17:58         ` One Thousand Gnomes
@ 2015-03-23 21:26           ` Pavel Machek
  0 siblings, 0 replies; 15+ messages in thread
From: Pavel Machek @ 2015-03-23 21:26 UTC (permalink / raw)
  To: One Thousand Gnomes
  Cc: Andy Lutomirski, Mark Seaborn, Kirill A. Shutemov, linux-mm,
	kernel list, Andrew Morton, Linus Torvalds, Kirill A. Shutemov,
	Pavel Emelyanov, Konstantin Khlebnikov


> > > 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.
> > 
> > We should definitely get Intel/AMD to disable CLFLUSH, then.
> 
> I doubt that would work, because you'd have to fix up all the faults from
> userspace in things like graphics and video. Whether it is possible to
> make the microcode do other accesses and delays I have no idea - but
> that might also be quite horrible.
> 
> A serious system should be using ECC memory anyway. and on things like
> shared boxes it is probably not a root compromise that is the worst case
> scenario but subtle undetected corruption of someone elses data
> sets.

Both are bad. It is fairly hard to do rowhammer by accident, so if you
are hitting it, someone is probably doing it on purpose. And cloud
providers seem to be case of "serious systems" without ECC...

(I seem to remember accidental rowhammer with spinlocks, will have to
check that again).

> That's what ECC already exists to protect against whether its from flawed
> memory and rowhammer or just a vindictive passing cosmic ray.

Well, there's more than thre orders of magnitude difference between
cosmic rays and rowhammer. IIRC cosmic rays are expected to cause 2
bit flips a year... rowhammer can do bitflip in 10 minutes, and that
is old version, not one of the optimized ones. 

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
  2015-03-23 21:26         ` Pavel Machek
@ 2015-03-23 22:36           ` Vlastimil Babka
  0 siblings, 0 replies; 15+ messages in thread
From: Vlastimil Babka @ 2015-03-23 22:36 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Andy Lutomirski, Mark Seaborn, Kirill A. Shutemov, linux-mm,
	kernel list, Andrew Morton, Linus Torvalds, Kirill A. Shutemov,
	Pavel Emelyanov, Konstantin Khlebnikov

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 <mseaborn@chromium.org> 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 :)



^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, back to index

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-09 21:11 [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace 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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org linux-kernel@archiver.kernel.org
	public-inbox-index lkml


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox