LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Vlastimil Babka <firstname.lastname@example.org> To: Andy Lutomirski <email@example.com>, Mark Seaborn <firstname.lastname@example.org> Cc: Pavel Machek <email@example.com>, "Kirill A. Shutemov" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, kernel list <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Linus Torvalds <email@example.com>, "Kirill A. Shutemov" <firstname.lastname@example.org>, Pavel Emelyanov <email@example.com>, Konstantin Khlebnikov <firstname.lastname@example.org> Subject: Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace Date: Thu, 19 Mar 2015 13:51:02 +0100 [thread overview] Message-ID: <550AC636.email@example.com> (raw) In-Reply-To: <CALCETrU8SeOTSexLOi36sX7Smwfv0baraK=A3hq8twoyBN7NBg@mail.gmail.com> On 03/17/2015 02:21 AM, Andy Lutomirski wrote: > On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn <firstname.lastname@example.org> wrote: >> On 16 March 2015 at 14:11, Pavel Machek <email@example.com> 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 firstname.lastname@example.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"email@example.com"> firstname.lastname@example.org </a> >
next prev parent reply other threads:[~2015-03-19 12:51 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 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 ` Vlastimil Babka [this message] 2015-03-23 21:26 ` [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=550AC636.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).