* Szabolcs Nagy: >> However, does it matter much? That's only for the initial setup, the >> user can then change the permissions directly via the sysreg. So maybe >> we don't need all those combinations upfront. A PKEY_DISABLE_EXECUTE >> together with the full PKEY_DISABLE_ACCESS would probably suffice. > > this is ok. > > a bit awkward in userspace when the register is directly > set to e.g write-only and pkey_get has to return something, > but we can handle settings outside of valid PKEY_* macros > as unspec, users who want that would use their own register > set/get code. > > i would have designed the permission to use either existing > PROT_* flags or say that it is architectural and written to > the register directly and let the libc wrapper deal with > portable api, i guess it's too late now. We can still define a portable API if we get a few more PKEY_* bits. The last attempt stalled because the kernel does not really need them, it would be for userspace benefit only. For performance-critical code, pkey_get/pkey_set are already too slow, so adding a bit more bit twiddling to it wouldn't be a proble, I think. Applications that want to change protection key bits around a very short code sequence will have to write the architecture-specific register. > (the signal handling behaviour should have a control and it > is possible to fix e.g. via pkey_alloc flags, but that may > not be the best solution and this can be done later.) For glibc, the POWER behavior is much more useful. Thanks, Florian
