[RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

[RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

[Kirill A. Shutemov]

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

Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

[Pavel Emelyanov]

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");
> 

Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

[Konstantin Khlebnikov]

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>

Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

[Kees Cook]

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

Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

[Andy Lutomirski]

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

Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

[Dave Hansen]

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?

Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

[Pavel Machek]

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

Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

[Mark Seaborn]

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

Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

[Andy Lutomirski]

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

rowhammer and pagemap (was Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace)

[Pavel Machek]

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

Re: rowhammer and pagemap (was Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace)

[One Thousand Gnomes]

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

Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

[Vlastimil Babka]

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

Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

[Pavel Machek]

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

Re: rowhammer and pagemap (was Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace)

[Pavel Machek]

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

Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

[Vlastimil Babka]

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