From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: MPK: removing a pkey Date: Thu, 23 Nov 2017 07:00:32 -0800 Message-ID: <17831167-7142-d42a-c7a0-59bdc8bbb786@linux.intel.com> References: <0f006ef4-a7b5-c0cf-5f58-d0fd1f911a54@redhat.com> <8741e4d6-6ac0-9c07-99f3-95d8d04940b4@suse.cz> <813f9736-36dd-b2e5-c850-9f2d5f94514a@redhat.com> <9ec19ff3-86f6-7cfe-1a07-1ab1c5d9882c@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Vlastimil Babka , Florian Weimer , linux-x86_64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Cc: linux-mm , Linux API List-Id: linux-api@vger.kernel.org On 11/23/2017 12:11 AM, Vlastimil Babka wrote: >> No, the default is clearly 0 and documented to be so. The PROT_EXEC >> emulation one should be inaccessible in all the APIs so does not even >> show up as *being* a key in the API. The fact that it's implemented >> with pkeys should be pretty immaterial other than the fact that you >> can't touch the high bits in PKRU. > So, just to be sure, if we call pkey_mprotect() with 0, will it blindly > set 0, or the result of arch_override_mprotect_pkey() (thus equivalent > to call with -1) ? I assume the latter? It's supposed to set 0. -1 was, as far as I remember, an internal-to-the-kernel-only thing to tell us that a key came from *mprotect()* instead of pkey_mprotect(). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com ([134.134.136.100]:1764 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751921AbdKWPAg (ORCPT ); Thu, 23 Nov 2017 10:00:36 -0500 Subject: Re: MPK: removing a pkey References: <0f006ef4-a7b5-c0cf-5f58-d0fd1f911a54@redhat.com> <8741e4d6-6ac0-9c07-99f3-95d8d04940b4@suse.cz> <813f9736-36dd-b2e5-c850-9f2d5f94514a@redhat.com> <9ec19ff3-86f6-7cfe-1a07-1ab1c5d9882c@redhat.com> From: Dave Hansen Message-ID: <17831167-7142-d42a-c7a0-59bdc8bbb786@linux.intel.com> Date: Thu, 23 Nov 2017 07:00:32 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Vlastimil Babka , Florian Weimer , linux-x86_64@vger.kernel.org, linux-arch@vger.kernel.org Cc: linux-mm , Linux API Message-ID: <20171123150032.6F9mRf7_q1WiiAZ9RXfar-smfRX12vn3mXXCRoueN-w@z> On 11/23/2017 12:11 AM, Vlastimil Babka wrote: >> No, the default is clearly 0 and documented to be so. The PROT_EXEC >> emulation one should be inaccessible in all the APIs so does not even >> show up as *being* a key in the API. The fact that it's implemented >> with pkeys should be pretty immaterial other than the fact that you >> can't touch the high bits in PKRU. > So, just to be sure, if we call pkey_mprotect() with 0, will it blindly > set 0, or the result of arch_override_mprotect_pkey() (thus equivalent > to call with -1) ? I assume the latter? It's supposed to set 0. -1 was, as far as I remember, an internal-to-the-kernel-only thing to tell us that a key came from *mprotect()* instead of pkey_mprotect(). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f199.google.com (mail-pf0-f199.google.com [209.85.192.199]) by kanga.kvack.org (Postfix) with ESMTP id 991CD6B0033 for ; Thu, 23 Nov 2017 10:00:37 -0500 (EST) Received: by mail-pf0-f199.google.com with SMTP id f6so305207pfe.16 for ; Thu, 23 Nov 2017 07:00:37 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com. [192.55.52.88]) by mx.google.com with ESMTPS id j1si16331455pgc.771.2017.11.23.07.00.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Nov 2017 07:00:36 -0800 (PST) Subject: Re: MPK: removing a pkey References: <0f006ef4-a7b5-c0cf-5f58-d0fd1f911a54@redhat.com> <8741e4d6-6ac0-9c07-99f3-95d8d04940b4@suse.cz> <813f9736-36dd-b2e5-c850-9f2d5f94514a@redhat.com> <9ec19ff3-86f6-7cfe-1a07-1ab1c5d9882c@redhat.com> From: Dave Hansen Message-ID: <17831167-7142-d42a-c7a0-59bdc8bbb786@linux.intel.com> Date: Thu, 23 Nov 2017 07:00:32 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka , Florian Weimer , linux-x86_64@vger.kernel.org, linux-arch@vger.kernel.org Cc: linux-mm , Linux API On 11/23/2017 12:11 AM, Vlastimil Babka wrote: >> No, the default is clearly 0 and documented to be so. The PROT_EXEC >> emulation one should be inaccessible in all the APIs so does not even >> show up as *being* a key in the API. The fact that it's implemented >> with pkeys should be pretty immaterial other than the fact that you >> can't touch the high bits in PKRU. > So, just to be sure, if we call pkey_mprotect() with 0, will it blindly > set 0, or the result of arch_override_mprotect_pkey() (thus equivalent > to call with -1) ? I assume the latter? It's supposed to set 0. -1 was, as far as I remember, an internal-to-the-kernel-only thing to tell us that a key came from *mprotect()* instead of pkey_mprotect(). -- 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