From: Ram Pai <linuxram@us.ibm.com> To: Andy Lutomirski <luto@kernel.org> Cc: Florian Weimer <fweimer@redhat.com>, Dave Hansen <dave.hansen@intel.com>, Linux API <linux-api@vger.kernel.org>, linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, Linux-MM <linux-mm@kvack.org> Subject: Re: pkeys: Reserve PKEY_DISABLE_READ Date: Wed, 5 Dec 2018 12:36:17 -0800 [thread overview] Message-ID: <20181205203617.GF11930@ram.oc3035372033.ibm.com> (raw) In-Reply-To: <CALCETrXeSQ8T9nvK7WpgPpkraLfg70FoDWvPZeLS3KiDaqXwtw@mail.gmail.com> On Wed, Dec 05, 2018 at 08:21:02AM -0800, Andy Lutomirski wrote: > > On Dec 2, 2018, at 8:02 PM, Ram Pai <linuxram@us.ibm.com> wrote: > > > >> On Thu, Nov 29, 2018 at 12:37:15PM +0100, Florian Weimer wrote: > >> * Dave Hansen: > >> > >>>> On 11/27/18 3:57 AM, Florian Weimer wrote: > >>>> I would have expected something that translates PKEY_DISABLE_WRITE | > >>>> PKEY_DISABLE_READ into PKEY_DISABLE_ACCESS, and also accepts > >>>> PKEY_DISABLE_ACCESS | PKEY_DISABLE_READ, for consistency with POWER. > >>>> > >>>> (My understanding is that PKEY_DISABLE_ACCESS does not disable all > >>>> access, but produces execute-only memory.) > >>> > >>> Correct, it disables all data access, but not execution. > >> > >> So I would expect something like this (completely untested, I did not > >> even compile this): > > > > > > Ok. I re-read through the entire email thread to understand the problem and > > the proposed solution. Let me summarize it below. Lets see if we are on the same > > plate. > > > > So the problem is as follows: > > > > Currently the kernel supports 'disable-write' and 'disable-access'. > > > > On x86, cpu supports 'disable-write' and 'disable-access'. This > > matches with what the kernel supports. All good. > > > > However on power, cpu supports 'disable-read' too. Since userspace can > > program the cpu directly, userspace has the ability to set > > 'disable-read' too. This can lead to inconsistency between the kernel > > and the userspace. > > > > We want the kernel to match userspace on all architectures. > > > > Proposed Solution: > > > > Enhance the kernel to understand 'disable-read', and facilitate architectures > > that understand 'disable-read' to allow it. > > > > Also explicitly define the semantics of disable-access as > > 'disable-read and disable-write' > > > > Did I get this right? Assuming I did, the implementation has to do > > the following -- > > > > On power, sys_pkey_alloc() should succeed if the init_val > > is PKEY_DISABLE_READ, PKEY_DISABLE_WRITE, PKEY_DISABLE_ACCESS > > or any combination of the three. > > > > On x86, sys_pkey_alloc() should succeed if the init_val is > > PKEY_DISABLE_WRITE or PKEY_DISABLE_ACCESS or PKEY_DISABLE_READ > > or any combination of the three, except PKEY_DISABLE_READ > > specified all by itself. > > > > On all other arches, none of the flags are supported. > > I don’t really love having a situation where you can use different > flag combinations to refer to the same mode. true. But it is a side-effect of x86 cpu implicitly defining 'disable-access' as a combination of 'disable-read' and 'disable_write'. In other words, if you disable-access on a pte on x86, you are automatically disabling read and disabling write on that page. The software/kernel just happens to explicitly capture that implicit behavior. > > Also, we should document the effect these flags have on execute permission. Actually none of the above flags, interact with execute permission. They operate independently; both on x86 and on POWER. But yes, this statement needs to be documented somewhere. RP
WARNING: multiple messages have this Message-ID (diff)
From: Ram Pai <linuxram@us.ibm.com> To: Andy Lutomirski <luto@kernel.org> Cc: Florian Weimer <fweimer@redhat.com>, Dave Hansen <dave.hansen@intel.com>, Linux-MM <linux-mm@kvack.org>, Linux API <linux-api@vger.kernel.org>, linuxppc-dev <linuxppc-dev@lists.ozlabs.org> Subject: Re: pkeys: Reserve PKEY_DISABLE_READ Date: Wed, 5 Dec 2018 12:36:17 -0800 [thread overview] Message-ID: <20181205203617.GF11930@ram.oc3035372033.ibm.com> (raw) In-Reply-To: <CALCETrXeSQ8T9nvK7WpgPpkraLfg70FoDWvPZeLS3KiDaqXwtw@mail.gmail.com> On Wed, Dec 05, 2018 at 08:21:02AM -0800, Andy Lutomirski wrote: > > On Dec 2, 2018, at 8:02 PM, Ram Pai <linuxram@us.ibm.com> wrote: > > > >> On Thu, Nov 29, 2018 at 12:37:15PM +0100, Florian Weimer wrote: > >> * Dave Hansen: > >> > >>>> On 11/27/18 3:57 AM, Florian Weimer wrote: > >>>> I would have expected something that translates PKEY_DISABLE_WRITE | > >>>> PKEY_DISABLE_READ into PKEY_DISABLE_ACCESS, and also accepts > >>>> PKEY_DISABLE_ACCESS | PKEY_DISABLE_READ, for consistency with POWER. > >>>> > >>>> (My understanding is that PKEY_DISABLE_ACCESS does not disable all > >>>> access, but produces execute-only memory.) > >>> > >>> Correct, it disables all data access, but not execution. > >> > >> So I would expect something like this (completely untested, I did not > >> even compile this): > > > > > > Ok. I re-read through the entire email thread to understand the problem and > > the proposed solution. Let me summarize it below. Lets see if we are on the same > > plate. > > > > So the problem is as follows: > > > > Currently the kernel supports 'disable-write' and 'disable-access'. > > > > On x86, cpu supports 'disable-write' and 'disable-access'. This > > matches with what the kernel supports. All good. > > > > However on power, cpu supports 'disable-read' too. Since userspace can > > program the cpu directly, userspace has the ability to set > > 'disable-read' too. This can lead to inconsistency between the kernel > > and the userspace. > > > > We want the kernel to match userspace on all architectures. > > > > Proposed Solution: > > > > Enhance the kernel to understand 'disable-read', and facilitate architectures > > that understand 'disable-read' to allow it. > > > > Also explicitly define the semantics of disable-access as > > 'disable-read and disable-write' > > > > Did I get this right? Assuming I did, the implementation has to do > > the following -- > > > > On power, sys_pkey_alloc() should succeed if the init_val > > is PKEY_DISABLE_READ, PKEY_DISABLE_WRITE, PKEY_DISABLE_ACCESS > > or any combination of the three. > > > > On x86, sys_pkey_alloc() should succeed if the init_val is > > PKEY_DISABLE_WRITE or PKEY_DISABLE_ACCESS or PKEY_DISABLE_READ > > or any combination of the three, except PKEY_DISABLE_READ > > specified all by itself. > > > > On all other arches, none of the flags are supported. > > I don’t really love having a situation where you can use different > flag combinations to refer to the same mode. true. But it is a side-effect of x86 cpu implicitly defining 'disable-access' as a combination of 'disable-read' and 'disable_write'. In other words, if you disable-access on a pte on x86, you are automatically disabling read and disabling write on that page. The software/kernel just happens to explicitly capture that implicit behavior. > > Also, we should document the effect these flags have on execute permission. Actually none of the above flags, interact with execute permission. They operate independently; both on x86 and on POWER. But yes, this statement needs to be documented somewhere. RP
next prev parent reply other threads:[~2018-12-05 20:36 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-08 12:05 pkeys: Reserve PKEY_DISABLE_READ Florian Weimer 2018-11-08 14:57 ` Dave Hansen 2018-11-08 15:01 ` Florian Weimer 2018-11-08 17:14 ` Dave Hansen 2018-11-08 17:37 ` Florian Weimer 2018-11-08 20:12 ` Ram Pai 2018-11-08 20:12 ` Ram Pai 2018-11-08 20:23 ` Florian Weimer 2018-11-08 20:23 ` Florian Weimer 2018-11-09 18:09 ` Ram Pai 2018-11-09 18:09 ` Ram Pai 2018-11-12 12:00 ` Florian Weimer 2018-11-12 12:00 ` Florian Weimer 2018-11-27 10:23 ` Ram Pai 2018-11-27 10:23 ` Ram Pai 2018-11-27 11:57 ` Florian Weimer 2018-11-27 11:57 ` Florian Weimer 2018-11-27 15:31 ` Dave Hansen 2018-11-27 15:31 ` Dave Hansen 2018-11-29 11:37 ` Florian Weimer 2018-11-29 11:37 ` Florian Weimer 2018-12-03 4:02 ` Ram Pai 2018-12-03 4:02 ` Ram Pai 2018-12-03 15:52 ` Florian Weimer 2018-12-03 15:52 ` Florian Weimer 2018-12-04 6:23 ` Ram Pai 2018-12-04 6:23 ` Ram Pai 2018-12-05 13:00 ` Florian Weimer 2018-12-05 13:00 ` Florian Weimer 2018-12-05 20:23 ` Ram Pai 2018-12-05 20:23 ` Ram Pai 2018-12-05 16:21 ` Andy Lutomirski 2018-12-05 16:21 ` Andy Lutomirski 2018-12-05 20:36 ` Ram Pai [this message] 2018-12-05 20:36 ` Ram Pai 2018-11-08 20:08 ` Ram Pai 2018-11-08 20:11 ` Dave Hansen 2018-11-08 20:14 ` Florian Weimer 2018-11-08 19:22 ` Ram Pai 2018-11-08 19:22 ` Ram Pai 2018-11-12 10:29 ` Florian Weimer 2018-11-12 10:29 ` Florian Weimer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181205203617.GF11930@ram.oc3035372033.ibm.com \ --to=linuxram@us.ibm.com \ --cc=dave.hansen@intel.com \ --cc=fweimer@redhat.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=luto@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.