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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Mar 2015 22:26:00 +0100
From:	Pavel Machek <pavel@....cz>
To:	Vlastimil Babka <vbabka@...e.cz>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Mark Seaborn <mseaborn@...omium.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Konstantin Khlebnikov <khlebnikov@...nvz.org>
Subject: Re: [RFC, PATCH] pagemap: do not leak physical addresses to
 non-privileged userspace

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@...omium.org> wrote:
> >> On 16 March 2015 at 14:11, Pavel Machek <pavel@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/