All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
	linux-api@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-mm@kvack.org
Subject: Re: pkeys: Reserve PKEY_DISABLE_READ
Date: Mon, 03 Dec 2018 16:52:02 +0100	[thread overview]
Message-ID: <87pnuibobh.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20181203040249.GA11930@ram.oc3035372033.ibm.com> (Ram Pai's message of "Sun, 2 Dec 2018 20:02:49 -0800")

* Ram Pai:

> 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.

Correct.

> 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.

Agreed.

> 	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.

Again agreed.  That's a clever way of phrasing it actually.

> 	On all other arches, none of the flags are supported.
>
>
> Are we on the same plate?

I think so, thanks.

Florian

WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
	linux-mm@kvack.org, linux-api@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: pkeys: Reserve PKEY_DISABLE_READ
Date: Mon, 03 Dec 2018 16:52:02 +0100	[thread overview]
Message-ID: <87pnuibobh.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20181203040249.GA11930@ram.oc3035372033.ibm.com> (Ram Pai's message of "Sun, 2 Dec 2018 20:02:49 -0800")

* Ram Pai:

> 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.

Correct.

> 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.

Agreed.

> 	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.

Again agreed.  That's a clever way of phrasing it actually.

> 	On all other arches, none of the flags are supported.
>
>
> Are we on the same plate?

I think so, thanks.

Florian

  reply	other threads:[~2018-12-03 15:52 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 [this message]
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
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=87pnuibobh.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=dave.hansen@intel.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=linuxram@us.ibm.com \
    /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: link
Be 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.