From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753753AbbCQLQ5 (ORCPT ); Tue, 17 Mar 2015 07:16:57 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:59603 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751571AbbCQLQz (ORCPT ); Tue, 17 Mar 2015 07:16:55 -0400 Date: Tue, 17 Mar 2015 12:16:53 +0100 From: Pavel Machek To: Andy Lutomirski Cc: Mark Seaborn , "Kirill A. Shutemov" , "linux-mm@kvack.org" , kernel list , Andrew Morton , Linus Torvalds , "Kirill A. Shutemov" , Pavel Emelyanov , Konstantin Khlebnikov Subject: rowhammer and pagemap (was Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace) Message-ID: <20150317111653.GA23711@amd> References: <1425935472-17949-1-git-send-email-kirill@shutemov.name> <20150316211122.GD11441@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > 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