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

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

Mar 9, 2015, 2:11 PM

Post #1 of 12 (2410 views)

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

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

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

xemul at parallels

Mar 9, 2015, 2:20 PM

Post #2 of 12 (2393 views)

Permalink

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

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

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

koct9i at gmail

Mar 9, 2015, 3:09 PM

Post #3 of 12 (2394 views)

Permalink

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

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

keescook at chromium

Mar 9, 2015, 5:11 PM

Post #4 of 12 (2393 views)

Permalink

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

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

luto at amacapital

Mar 9, 2015, 5:19 PM

Post #5 of 12 (2391 views)

Permalink

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

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

dave.hansen at linux

Mar 9, 2015, 7:36 PM

Post #6 of 12 (2388 views)

Permalink

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?

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

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

pavel at ucw

Mar 16, 2015, 2:11 PM

Post #7 of 12 (2385 views)

Permalink

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

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

mseaborn at chromium

Mar 16, 2015, 5:49 PM

Post #8 of 12 (2385 views)

Permalink

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

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

luto at amacapital

Mar 16, 2015, 6:21 PM

Post #9 of 12 (2389 views)

Permalink

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

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

vbabka at suse

Mar 19, 2015, 5:51 AM

Post #10 of 12 (2370 views)

Permalink

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

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

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

pavel at ucw

Mar 23, 2015, 2:26 PM

Post #11 of 12 (2369 views)

Permalink

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

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

vbabka at suse

Mar 23, 2015, 3:36 PM

Post #12 of 12 (2372 views)

Permalink

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

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