All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: linux-mm@kvack.org, Dave Hansen <dave.hansen@intel.com>,
	linuxppc-dev@lists.ozlabs.org, linux-api@vger.kernel.org
Subject: Re: pkeys: Reserve PKEY_DISABLE_READ
Date: Thu, 8 Nov 2018 12:12:31 -0800	[thread overview]
Message-ID: <20181108201231.GE5481@ram.oc3035372033.ibm.com> (raw)
In-Reply-To: <87k1ln8o7u.fsf@oldenburg.str.redhat.com>

On Thu, Nov 08, 2018 at 06:37:41PM +0100, Florian Weimer wrote:
> * Dave Hansen:
> 
> > On 11/8/18 7:01 AM, Florian Weimer wrote:
> >> Ideally, PKEY_DISABLE_READ | PKEY_DISABLE_WRITE and PKEY_DISABLE_READ |
> >> PKEY_DISABLE_ACCESS would be treated as PKEY_DISABLE_ACCESS both, and a
> >> line PKEY_DISABLE_READ would result in an EINVAL failure.
> >
> > Sounds reasonable to me.
> >
> > I don't see any urgency to do this right now.  It could easily go in
> > alongside the ppc patches when those get merged.
> 
> POWER support has already been merged, so we need to do something here
> now, before I can complete the userspace side.
> 
> > The only thing I'd suggest is that we make it something slightly
> > higher than 0x4.  It'll make the code easier to deal with in the
> > kernel if we have the ABI and the hardware mirror each other, and if
> > we pick 0x4 in the ABI for PKEY_DISABLE_READ, it might get messy if
> > the harware choose 0x4 for PKEY_DISABLE_EXECUTE or something.
> > 
> > So, let's make it 0x80 or something on x86 at least.
> 
> I don't have a problem with that if that's what it takes.
> 
> > Also, I'll be happy to review and ack the patch to do this, but I'd
> > expect the ppc guys (hi Ram!) to actually put it together.
> 
> Ram, do you want to write a patch?


Florian,

	I can. But I am struggling to understand the requirement. Why is
	this needed?  Are we proposing a enhancement to the sys_pkey_alloc(),
	to be able to allocate keys that are initialied to disable-read
	only?

RP

> 
> I'll promise I finish the glibc support for this. 8-)
> 
> Thanks,
> Florian

-- 
Ram Pai

WARNING: multiple messages have this Message-ID (diff)
From: Ram Pai <linuxram@us.ibm.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
	linux-api@vger.kernel.org, linux-mm@kvack.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: pkeys: Reserve PKEY_DISABLE_READ
Date: Thu, 8 Nov 2018 12:12:31 -0800	[thread overview]
Message-ID: <20181108201231.GE5481@ram.oc3035372033.ibm.com> (raw)
In-Reply-To: <87k1ln8o7u.fsf@oldenburg.str.redhat.com>

On Thu, Nov 08, 2018 at 06:37:41PM +0100, Florian Weimer wrote:
> * Dave Hansen:
> 
> > On 11/8/18 7:01 AM, Florian Weimer wrote:
> >> Ideally, PKEY_DISABLE_READ | PKEY_DISABLE_WRITE and PKEY_DISABLE_READ |
> >> PKEY_DISABLE_ACCESS would be treated as PKEY_DISABLE_ACCESS both, and a
> >> line PKEY_DISABLE_READ would result in an EINVAL failure.
> >
> > Sounds reasonable to me.
> >
> > I don't see any urgency to do this right now.  It could easily go in
> > alongside the ppc patches when those get merged.
> 
> POWER support has already been merged, so we need to do something here
> now, before I can complete the userspace side.
> 
> > The only thing I'd suggest is that we make it something slightly
> > higher than 0x4.  It'll make the code easier to deal with in the
> > kernel if we have the ABI and the hardware mirror each other, and if
> > we pick 0x4 in the ABI for PKEY_DISABLE_READ, it might get messy if
> > the harware choose 0x4 for PKEY_DISABLE_EXECUTE or something.
> > 
> > So, let's make it 0x80 or something on x86 at least.
> 
> I don't have a problem with that if that's what it takes.
> 
> > Also, I'll be happy to review and ack the patch to do this, but I'd
> > expect the ppc guys (hi Ram!) to actually put it together.
> 
> Ram, do you want to write a patch?


Florian,

	I can. But I am struggling to understand the requirement. Why is
	this needed?  Are we proposing a enhancement to the sys_pkey_alloc(),
	to be able to allocate keys that are initialied to disable-read
	only?

RP

> 
> I'll promise I finish the glibc support for this. 8-)
> 
> Thanks,
> Florian

-- 
Ram Pai

  reply	other threads:[~2018-11-08 20:12 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 [this message]
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
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=20181108201231.GE5481@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 \
    /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.