On 12/18/2017 02:18 PM, Ram Pai wrote: > b) minimum number of keys available to the application. > if libraries consumes a few, they could provide a library > interface to the application informing the number available to > the application. The library interface can leverage (b) to > provide the information. OK, let's see a real user of this including a few libraries. Then we'll put it in the kernel. > c) types of disable-rights supported by keys. > Helps the application to determine the types of disable-features > available. This is helpful, otherwise the app has to > make pkey_alloc() call with the corresponding parameter set > and see if it suceeds or fails. Painful from an application > point of view, in my opinion. Again, let's see a real-world use of this. How does it look? How does an app "fall back" if it can't set a restriction the way it wants to? Are we *sure* that such an interface makes sense? For instance, will it be possible for some keys to be execute-disable while other are only write-disable? > I think on x86 you look for some hardware registers to determine which > hardware features are enabled by the kernel. No, we use CPUID. It's a part of the ISA that's designed for enumerating CPU and (sometimes) OS support for CPU features. > We do not have generic support for something like that on ppc. > The kernel looks at the device tree to determine what hardware features > are available. But does not have mechanism to tell the hardware to track > which of its features are currently enabled/used by the kernel; atleast > not for the memory-key feature. Bummer. You're missing out. But, you could still do this with a syscall. "Hey, kernel, do you support this feature?"
