On Thu, Nov 08, 2018 at 09:14:54AM -0800, Dave Hansen wrote: > 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. 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. The hardware bits have to be decoupled from the software bits. Otherwise we will get too constrainted and will conflict with the bit configuration of some hardware. Powerpc implementation can deal with 0x4 or any other value. > > So, let's make it 0x80 or something on x86 at least. > > 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. Hi Dave! :) So what is needed? Support a new flag PKEY_DISABLE_READ, and make it return error for all architectures? Or are we enhancing the symantics of pkey_alloc() to allocate keys with just disable-read permissions.? And if so, will x86 be able to support that semantics? -- Ram Pai
