Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2017-07-11 22:09:44
Also in:
linux-arch, linux-mm, lkml
On Tue, 2017-07-11 at 14:51 -0700, Ram Pai wrote:
On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:quoted
On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:quoted
On 07/05/2017 02:21 PM, Ram Pai wrote:quoted
Currently sys_pkey_create() provides the ability to disable read and write permission on the key, at creation. powerpc has the hardware support to disable execute on a pkey as well.This patch enhances the interface to let disable execute at key creation time. x86 does not allow this. Hence the next patch will add ability in x86 to return error if PKEY_DISABLE_EXECUTE is specified.That leads to the question... How do you tell userspace. (apologies if I missed that in an existing patch in the series) How do we inform userspace of the key capabilities ? There are at least two things userspace may want to know already: - What protection bits are supported for a keythe userspace is the one which allocates the keys and enables/disables the protection bits on the key. the kernel is just a facilitator. Now if the use space wants to know the current permissions on a given key, it can just read the AMR/PKRU register on powerpc/intel respectively.
You misunderstand. How does userspace knows on a given system whether execute permission control is supported for keys ?
quoted
- How many keys existThere is no standard way of finding this other than trying to allocate as many till you fail. A procfs or sysfs file can be added to expose this information.quoted
- Which keys are available for use by userspace. On PowerPC, the kernel can reserve some keys for itself, so can the hypervisor. In fact, they do.this information can be exposed through /proc or /sysfs I am sure there will be more demands and requirements as applications start leveraging these feature. RPquoted
Cheers, Ben.