Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751978AbbFYO0w (ORCPT ); Thu, 25 Jun 2015 10:26:52 -0400 Received: from mail-lb0-f176.google.com ([209.85.217.176]:32876 "EHLO mail-lb0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751595AbbFYO0g (ORCPT ); Thu, 25 Jun 2015 10:26:36 -0400 MIME-Version: 1.0 In-Reply-To: <20150625141638.GF2329@akamai.com> References: <1433942810-7852-1-git-send-email-emunson@akamai.com> <20150610145929.b22be8647887ea7091b09ae1@linux-foundation.org> <5579DFBA.80809@akamai.com> <20150611123424.4bb07cffd0e5bb146cc92231@linux-foundation.org> <557ACAFC.90608@suse.cz> <20150615144356.GB12300@akamai.com> <55895956.5020707@suse.cz> <20150625141638.GF2329@akamai.com> From: Andy Lutomirski Date: Thu, 25 Jun 2015 07:26:14 -0700 Message-ID: Subject: Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault To: Eric B Munson Cc: Vlastimil Babka , Andrew Morton , Shuah Khan , Michal Hocko , Michael Kerrisk , linux-alpha@vger.kernel.org, "linux-kernel@vger.kernel.org" , Linux MIPS Mailing List , linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, "linux-mm@kvack.org" , linux-arch , Linux API Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1176 Lines: 28 On Thu, Jun 25, 2015 at 7:16 AM, Eric B Munson wrote: > On Tue, 23 Jun 2015, Vlastimil Babka wrote: > >> On 06/15/2015 04:43 PM, Eric B Munson wrote: >> >> >> >>If the new LOCKONFAULT functionality is indeed desired (I haven't >> >>still decided myself) then I agree that would be the cleanest way. >> > >> >Do you disagree with the use cases I have listed or do you think there >> >is a better way of addressing those cases? >> >> I'm somewhat sceptical about the security one. Are security >> sensitive buffers that large to matter? The performance one is more >> convincing and I don't see a better way, so OK. > > They can be, the two that come to mind are medical images and high > resolution sensor data. I think we've been handling sensitive memory pages wrong forever. We shouldn't lock them into memory; we should flag them as sensitive and encrypt them if they're ever written out to disk. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/