From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751186AbbCJExV (ORCPT ); Tue, 10 Mar 2015 00:53:21 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:43951 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750773AbbCJExT (ORCPT ); Tue, 10 Mar 2015 00:53:19 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Dave Hansen Cc: Kees Cook , Andrew Morton , "Theodore Ts'o" , Oleg Nesterov , LKML , Dave Hansen References: <20150309204321.AAF412E0@viggo.jf.intel.com> <878uf5vmxo.fsf@x220.int.ebiederm.org> <87h9ttrcpr.fsf@x220.int.ebiederm.org> <878uf5rb3v.fsf@x220.int.ebiederm.org> <54FE5C28.10305@intel.com> Date: Mon, 09 Mar 2015 23:49:39 -0500 In-Reply-To: <54FE5C28.10305@intel.com> (Dave Hansen's message of "Mon, 09 Mar 2015 19:51:20 -0700") Message-ID: <87twxtpicc.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1+N9WG5wloRo0efdHmf2cMJ6jPrO/eqO58= X-SA-Exim-Connect-IP: 70.59.163.10 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 XMNoVowels Alpha-numberic number with no vowels * 1.5 TR_Symld_Words too many words that have symbols inside * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;Dave Hansen X-Spam-Relay-Country: X-Spam-Timing: total 224 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 4.9 (2.2%), b_tie_ro: 3.3 (1.5%), parse: 1.19 (0.5%), extract_message_metadata: 14 (6.2%), get_uri_detail_list: 1.30 (0.6%), tests_pri_-1000: 7 (3.0%), tests_pri_-950: 1.18 (0.5%), tests_pri_-900: 0.99 (0.4%), tests_pri_-400: 21 (9.2%), check_bayes: 20 (8.7%), b_tokenize: 5 (2.4%), b_tok_get_all: 6 (2.9%), b_comp_prob: 2.2 (1.0%), b_tok_touch_all: 3.3 (1.5%), b_finish: 0.68 (0.3%), tests_pri_0: 168 (75.0%), tests_pri_500: 3.6 (1.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFC][PATCH 1/2] fs proc: make pagemap a privileged interface X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dave Hansen writes: > On 03/09/2015 05:03 PM, Kees Cook wrote: >> On Mon, Mar 9, 2015 at 4:43 PM, Eric W. Biederman wrote: >>> A 1 to 1 blinding function like integer multiplication mudulo 2^32 by an >>> appropriate random number ought to keep from revealing page numbers or >>> page ajacencies while not requiring any changes in userspace. >>> >>> That way the revealed pfn and the physcial pfn would be different but >>> you could still use pagemap for it's intended purpose. >> >> If this could be done in a way where it was sufficiently hard to >> expose the random number, we should absolutely do this. > > We would need something which is both reversible (so that the given > offsets can still be used in /proc/kpagemap) and also hard to do a > known-plaintext-type attack on it. > > Transparent huge pages are a place where userspace knows the > relationship between 512 adjacent physical addresses. That represents a > good chunk of known data. Surely there are more of these kinds of things. > > Right now, for instance, the ways in which a series of sequential > allocations come out of the page allocator are fairly deterministic. We > would also need to do some kind of allocator randomization to ensure > that userspace couldn't make good guesses about the physical addresses > of things coming out of the allocator. > > Or, we just be sure and turn the darn thing off. :) Yes. If we are worried about something a big off switch is fine. As for a one-to-one transform that is resitant to plain text attacks I think that is the definition of a cypher. That is we should just use AES or something well know to encrypt the pafe frame numbers if we want to hide them. I don't know if the block mode of AES would be a problem or not. Eric