From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753223AbbCQBWL (ORCPT ); Mon, 16 Mar 2015 21:22:11 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:32949 "EHLO mail-lb0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751385AbbCQBWI (ORCPT ); Mon, 16 Mar 2015 21:22:08 -0400 MIME-Version: 1.0 In-Reply-To: References: <1425935472-17949-1-git-send-email-kirill@shutemov.name> <20150316211122.GD11441@amd> From: Andy Lutomirski Date: Mon, 16 Mar 2015 18:21:44 -0700 Message-ID: Subject: Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace To: Mark Seaborn Cc: Pavel Machek , "Kirill A. Shutemov" , "linux-mm@kvack.org" , kernel list , Andrew Morton , Linus Torvalds , "Kirill A. Shutemov" , Pavel Emelyanov , Konstantin Khlebnikov Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn wrote: > On 16 March 2015 at 14:11, Pavel Machek wrote: >> On Mon 2015-03-09 23:11:12, Kirill A. Shutemov wrote: >> > From: "Kirill A. Shutemov" >> > >> > 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