On Mon, Dec 18, 2017 at 03:15:51PM -0800, Ram Pai wrote: > On Mon, Dec 18, 2017 at 02:28:14PM -0800, Dave Hansen wrote: > > 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? > > Can it be on x86? > > its not possible on ppc. the keys can *all* be the-same-attributes-disable all the > time. > > However you are right. Its conceivable that some arch could provide a > feature where it can be x-attribute-disable for key 'a' and > y-attribute-disable for key 'b'. But than its a bit of a headache > for an application to consume such a feature. > > Ben: I recall you requesting this feature. Thoughts? > > > > > > 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?" > > or do powerpc specific sysfs interface. > or a debugfs interface. getauxval(3) ? With AT_HWCAP or HWCAP2 as parameter already gives information about features supported by the hardware and the kernel. Taking one bit to expose the availability of protection keys to applications does not look impossible. Do I miss something obvious? Gabriel -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
