From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759083AbcGKOe7 (ORCPT ); Mon, 11 Jul 2016 10:34:59 -0400 Received: from www.sr71.net ([198.145.64.142]:39988 "EHLO blackbird.sr71.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759064AbcGKOe5 (ORCPT ); Mon, 11 Jul 2016 10:34:57 -0400 Subject: Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls To: Andy Lutomirski , Ingo Molnar References: <20160707124719.3F04C882@viggo.jf.intel.com> <20160707124728.C1116BB1@viggo.jf.intel.com> <20160707144508.GZ11498@techsingularity.net> <577E924C.6010406@sr71.net> <20160708071810.GA27457@gmail.com> <577FD587.6050101@sr71.net> <20160709083715.GA29939@gmail.com> Cc: linux-arch , Thomas Gleixner , "linux-mm@kvack.org" , Mel Gorman , Linus Torvalds , Andrew Morton , Linux API , Arnd Bergmann , "linux-kernel@vger.kernel.org" , Al Viro , Peter Zijlstra , Hugh Dickins , "H. Peter Anvin" , X86 ML , Dave Hansen From: Dave Hansen Message-ID: <5783AE8F.3@sr71.net> Date: Mon, 11 Jul 2016 07:34:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/10/2016 09:25 PM, Andy Lutomirski wrote: > 2. When thread A allocates a pkey, how does it lock down thread B? > > #2 could be addressed by using fully-locked-down as the initial state > post-exec() and copying the state on clone(). Dave, are there any > cases in practice where one thread would allocate a pkey and want > other threads to immediately have access to the memory with that key? The only one I can think of is a model where pkeys are used more in a "denial" mode rather than an "allow" mode. For instance, perhaps you don't want to modify your app to use pkeys, except for a small routine where you handle untrusted user data. You would, in that routine, deny access to a bunch of keys, but otherwise allow access to all so you didn't have to change any other parts of the app. Should we instead just recommend to userspace that they lock down access to keys by default in all threads as a best practice? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls Date: Mon, 11 Jul 2016 07:34:55 -0700 Message-ID: <5783AE8F.3@sr71.net> References: <20160707124719.3F04C882@viggo.jf.intel.com> <20160707124728.C1116BB1@viggo.jf.intel.com> <20160707144508.GZ11498@techsingularity.net> <577E924C.6010406@sr71.net> <20160708071810.GA27457@gmail.com> <577FD587.6050101@sr71.net> <20160709083715.GA29939@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andy Lutomirski , Ingo Molnar Cc: linux-arch , Thomas Gleixner , "linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org" , Mel Gorman , Linus Torvalds , Andrew Morton , Linux API , Arnd Bergmann , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Al Viro , Peter Zijlstra , Hugh Dickins , "H. Peter Anvin" , X86 ML , Dave Hansen List-Id: linux-api@vger.kernel.org On 07/10/2016 09:25 PM, Andy Lutomirski wrote: > 2. When thread A allocates a pkey, how does it lock down thread B? > > #2 could be addressed by using fully-locked-down as the initial state > post-exec() and copying the state on clone(). Dave, are there any > cases in practice where one thread would allocate a pkey and want > other threads to immediately have access to the memory with that key? The only one I can think of is a model where pkeys are used more in a "denial" mode rather than an "allow" mode. For instance, perhaps you don't want to modify your app to use pkeys, except for a small routine where you handle untrusted user data. You would, in that routine, deny access to a bunch of keys, but otherwise allow access to all so you didn't have to change any other parts of the app. Should we instead just recommend to userspace that they lock down access to keys by default in all threads as a best practice? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f72.google.com (mail-pa0-f72.google.com [209.85.220.72]) by kanga.kvack.org (Postfix) with ESMTP id C73676B0262 for ; Mon, 11 Jul 2016 10:34:57 -0400 (EDT) Received: by mail-pa0-f72.google.com with SMTP id ib6so225136884pad.0 for ; Mon, 11 Jul 2016 07:34:57 -0700 (PDT) Received: from blackbird.sr71.net (www.sr71.net. [198.145.64.142]) by mx.google.com with ESMTP id u3si609931pay.67.2016.07.11.07.34.56 for ; Mon, 11 Jul 2016 07:34:57 -0700 (PDT) Subject: Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls References: <20160707124719.3F04C882@viggo.jf.intel.com> <20160707124728.C1116BB1@viggo.jf.intel.com> <20160707144508.GZ11498@techsingularity.net> <577E924C.6010406@sr71.net> <20160708071810.GA27457@gmail.com> <577FD587.6050101@sr71.net> <20160709083715.GA29939@gmail.com> From: Dave Hansen Message-ID: <5783AE8F.3@sr71.net> Date: Mon, 11 Jul 2016 07:34:55 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski , Ingo Molnar Cc: linux-arch , Thomas Gleixner , "linux-mm@kvack.org" , Mel Gorman , Linus Torvalds , Andrew Morton , Linux API , Arnd Bergmann , "linux-kernel@vger.kernel.org" , Al Viro , Peter Zijlstra , Hugh Dickins , "H. Peter Anvin" , X86 ML , Dave Hansen On 07/10/2016 09:25 PM, Andy Lutomirski wrote: > 2. When thread A allocates a pkey, how does it lock down thread B? > > #2 could be addressed by using fully-locked-down as the initial state > post-exec() and copying the state on clone(). Dave, are there any > cases in practice where one thread would allocate a pkey and want > other threads to immediately have access to the memory with that key? The only one I can think of is a model where pkeys are used more in a "denial" mode rather than an "allow" mode. For instance, perhaps you don't want to modify your app to use pkeys, except for a small routine where you handle untrusted user data. You would, in that routine, deny access to a bunch of keys, but otherwise allow access to all so you didn't have to change any other parts of the app. Should we instead just recommend to userspace that they lock down access to keys by default in all threads as a best practice? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org