The 06/17/2024 15:40, Florian Weimer wrote: > >> A user can still set it by interacting with the register directly, but I guess > >> we want something for the glibc interface.. > >> > >> Dave, any thoughts here? > > > > adding Florian too, since i found an old thread of his that tried > > to add separate PKEY_DISABLE_READ and PKEY_DISABLE_EXECUTE, but > > it did not seem to end up upstream. (this makes more sense to me > > as libc api than the weird disable access semantics) > > I still think it makes sense to have a full complenent of PKEY_* flags > complementing the PROT_* flags, in a somewhat abstract fashion for > pkey_alloc only. The internal protection mask register encoding will > differ from architecture to architecture, but the abstract glibc > functions pkey_set and pkey_get could use them (if we are a bit > careful). to me it makes sense to have abstract PKEY_DISABLE_READ PKEY_DISABLE_WRITE PKEY_DISABLE_EXECUTE PKEY_DISABLE_ACCESS where access is handled like if (flags&PKEY_DISABLE_ACCESS) flags |= PKEY_DISABLE_READ|PKEY_DISABLE_WRITE; disable_read = flags&PKEY_DISABLE_READ; disable_write = flags&PKEY_DISABLE_WRITE; disable_exec = flags&PKEY_DISABLE_EXECUTE; if there are unsupported combinations like disable_read&&!disable_write then those are rejected by pkey_alloc and pkey_set. this allows portable use of pkey apis. (the flags could be target specific, but don't have to be)
