Assortment of fixes to pkey to match its behavior to that on x86.
Patch 1 makes pkey consumable in multithreaded applications.
Patch 2 Deny, by default, permissions on all unallocated keys.
Patch 3 pkey allocation/free must not change pkey registers.
Patch 4 fixes fork to inherit the key attributes.
Patch 5 A off-by-one bug made one key unusable. Fixes it.
Patch 6 Makes pkey-0 less special.
Patch 7 fix to core-pkeys selftest to capture the modified behavior
Patch 8 fix to ptrace-pkeys selftest to capture the modified behavior
The above patch series is successfully verified using pkey selftests,
on both powerpc and x86.
Ram Pai (9):
powerpc/pkeys: Give all threads control of their key permissions
powerpc/pkeys: Deny read/write/execute by default
powerpc/pkeys: key allocation/deallocation must not change pkey
registers
powerpc/pkeys: Save the pkey registers before fork
powerpc/pkeys: fix calculation of total pkeys.
powerpc/pkeys: Preallocate execute-only key
powerpc/pkeys: make protection key 0 less special
powerpc/core-pkeys: execute-permission on keys are disabled by
default
powerpc/ptrace-pkeys: execute-permission on keys are disabled by
default
arch/powerpc/include/asm/pkeys.h | 40 +++---
arch/powerpc/kernel/process.c | 1 +
arch/powerpc/mm/pkeys.c | 141 +++++++-------------
tools/testing/selftests/powerpc/ptrace/core-pkey.c | 4 +
.../testing/selftests/powerpc/ptrace/ptrace-pkey.c | 5 +
5 files changed, 79 insertions(+), 112 deletions(-)
Currently in a multithreaded application, a key allocated by one
thread is not usable by other threads. By "not usable" we mean that
other threads are unable to change the access permissions for that
key for themselves.
When a new key is allocated in one thread, the corresponding UAMOR
bits for that thread get enabled, however the UAMOR bits for that key
for all other threads remain disabled.
Other threads have no way to set permissions on the key, and the
current default permissions are that read/write is enabled for all
keys, which means the key has no effect for other threads. Although
that may be the desired behaviour in some circumstances, having all
threads able to control their permissions for the key is more
flexible.
The current behaviour also differs from the x86 behaviour, which is
problematic for users.
To fix this, enable the UAMOR bits for all keys, at process
creation (in start_thread(), ie exec time). Since the contents of
UAMOR are inherited at fork, all threads are capable of modifying the
permissions on any key.
This is technically an ABI break on powerpc, but pkey support is fairly
new on powerpc and not widely used, and this brings us into
line with x86.
Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem")
Cc: stable@vger.kernel.org # v4.16+
Tested-by: Florian Weimer <redacted>
Signed-off-by: Ram Pai <redacted>
[mpe: Reword some of the changelog]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/mm/pkeys.c | 44 ++++++++++++++++++++++++++------------------
1 files changed, 26 insertions(+), 18 deletions(-)
@@ -15,8 +15,9 @@intpkeys_total;/* Total pkeys as per device tree */boolpkeys_devtree_defined;/* pkey property exported by device tree */u32initial_allocation_mask;/* Bits set for reserved keys */-u64pkey_amr_uamor_mask;/* Bits in AMR/UMOR not to be touched */+u64pkey_amr_mask;/* Bits in AMR not to be touched */u64pkey_iamr_mask;/* Bits in AMR not to be touched */+u64pkey_uamor_mask;/* Bits in UMOR not to be touched */#define AMR_BITS_PER_PKEY 2#define AMR_RD_BIT 0x1UL
@@ -119,20 +120,26 @@ int pkey_initialize(void)#elseos_reserved=0;#endif-initial_allocation_mask=~0x0;-pkey_amr_uamor_mask=~0x0ul;+initial_allocation_mask=(0x1<<0)|(0x1<<1);++/* register mask is in BE format */+pkey_amr_mask=~0x0ul;pkey_iamr_mask=~0x0ul;-/*-*key0,1arereserved.-*key0isthedefaultkey,whichallowsread/write/execute.-*key1isrecommendednottobeused.PowerISA(3.0)page1015,-*programmingnote.-*/-for(i=2;i<(pkeys_total-os_reserved);i++){-initial_allocation_mask&=~(0x1<<i);-pkey_amr_uamor_mask&=~(0x3ul<<pkeyshift(i));++for(i=0;i<(pkeys_total-os_reserved);i++){+pkey_amr_mask&=~(0x3ul<<pkeyshift(i));pkey_iamr_mask&=~(0x1ul<<pkeyshift(i));}++pkey_uamor_mask=~0x0ul;+pkey_uamor_mask&=~(0x3ul<<pkeyshift(0));++/* mark the rest of the keys as reserved and hence unavailable */+for(i=(pkeys_total-os_reserved);i<pkeys_total;i++){+initial_allocation_mask|=(0x1<<i);+pkey_uamor_mask&=~(0x3ul<<pkeyshift(i));+}+return0;}
Deny all permissions on all keys, with some exceptions. pkey-0 must
allow all permissions, or else everything comes to a screaching halt.
Execute-only key must allow execute permission.
Signed-off-by: Ram Pai <redacted>
---
arch/powerpc/mm/pkeys.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
@@ -124,12 +124,10 @@ int pkey_initialize(void)/* register mask is in BE format */pkey_amr_mask=~0x0ul;-pkey_iamr_mask=~0x0ul;+pkey_amr_mask&=~(0x3ul<<pkeyshift(0));-for(i=0;i<(pkeys_total-os_reserved);i++){-pkey_amr_mask&=~(0x3ul<<pkeyshift(i));-pkey_iamr_mask&=~(0x1ul<<pkeyshift(i));-}+pkey_iamr_mask=~0x0ul;+pkey_iamr_mask&=~(0x3ul<<pkeyshift(0));pkey_uamor_mask=~0x0ul;pkey_uamor_mask&=~(0x3ul<<pkeyshift(0));
Key allocation and deallocation has the side effect of programming the
UAMOR/AMR/IAMR registers. This is wrong, since its the responsibility of
the application and not that of the kernel, to modify the permission on
the key.
Do not modify the pkey registers at key allocation/deallocation.
This patch also fixes a bug where a sys_pkey_free() resets the UAMOR
bits of the key, thus making its permissions unmodifiable from user
space. Later if the same key gets reallocated from a different thread
this thread will no longer be able to change the permissions on the key.
Reviewed-by: Thiago Jung Bauermann <redacted>
Signed-off-by: Ram Pai <redacted>
---
arch/powerpc/include/asm/pkeys.h | 11 -----------
arch/powerpc/mm/pkeys.c | 27 ---------------------------
2 files changed, 0 insertions(+), 38 deletions(-)
@@ -218,33 +218,6 @@ static inline void init_iamr(int pkey, u8 init_bits)write_iamr(old_iamr|new_iamr_bits);}-staticvoidpkey_status_change(intpkey,boolenable)-{-u64old_uamor;--/* Reset the AMR and IAMR bits for this key */-init_amr(pkey,0x0);-init_iamr(pkey,0x0);--/* Enable/disable key */-old_uamor=read_uamor();-if(enable)-old_uamor|=(0x3ul<<pkeyshift(pkey));-else-old_uamor&=~(0x3ul<<pkeyshift(pkey));-write_uamor(old_uamor);-}--void__arch_activate_pkey(intpkey)-{-pkey_status_change(pkey,true);-}--void__arch_deactivate_pkey(intpkey)-{-pkey_status_change(pkey,false);-}-/**SettheaccessrightsinAMRIAMRandUAMORregistersfor@pkeytothat*specifiedin@init_val.
When a thread forks the contents of AMR, IAMR, UAMOR registers in the
newly forked thread are not inherited.
Save the registers before forking, for content of those
registers to be automatically copied into the new thread.
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Florian Weimer <redacted>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Thiago Jung Bauermann <redacted>
Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem")
Cc: stable@vger.kernel.org # v4.16+
Signed-off-by: Ram Pai <redacted>
---
arch/powerpc/kernel/process.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Total number of pkeys calculation is off by 1. Fix it.
Cc: Florian Weimer <redacted>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thiago Jung Bauermann <redacted>
Fixes: 4fb158f65ac5 ("powerpc: track allocation status of all pkeys")
Cc: stable@vger.kernel.org # v4.16+
Signed-off-by: Ram Pai <redacted>
---
arch/powerpc/mm/pkeys.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
execute-only key is allocated dynamically. This is a problem. When a
thread implicitly creates a execute-only key, and resets UAMOR for that
key, the UAMOR value does not percolate to all the other threads. Any
other thread may ignorantly change the permissions on the key. This can
cause the key to be not execute-only for that thread.
Preallocate the execute-only key and ensure that no thread can change
the permission of the key, by resetting the corresponding bit in UAMOR.
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Florian Weimer <redacted>
Cc: Thiago Jung Bauermann <redacted>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Fixes: 5586cf61e108 ("powerpc: introduce execute-only pkey")
Cc: stable@vger.kernel.org # v4.16+
Signed-off-by: Ram Pai <redacted>
---
arch/powerpc/mm/pkeys.c | 63 +++++++++++++---------------------------------
1 files changed, 18 insertions(+), 45 deletions(-)
@@ -18,6 +18,7 @@u64pkey_amr_mask;/* Bits in AMR not to be touched */u64pkey_iamr_mask;/* Bits in AMR not to be touched */u64pkey_uamor_mask;/* Bits in UMOR not to be touched */+intexecute_only_key=2;#define AMR_BITS_PER_PKEY 2#define AMR_RD_BIT 0x1UL
@@ -120,7 +121,8 @@ int pkey_initialize(void)#elseos_reserved=0;#endif-initial_allocation_mask=(0x1<<0)|(0x1<<1);+initial_allocation_mask=(0x1<<0)|(0x1<<1)|+(0x1<<execute_only_key);/* register mask is in BE format */pkey_amr_mask=~0x0ul;
@@ -128,9 +130,11 @@ int pkey_initialize(void)pkey_iamr_mask=~0x0ul;pkey_iamr_mask&=~(0x3ul<<pkeyshift(0));+pkey_iamr_mask&=~(0x3ul<<pkeyshift(execute_only_key));pkey_uamor_mask=~0x0ul;pkey_uamor_mask&=~(0x3ul<<pkeyshift(0));+pkey_uamor_mask&=~(0x3ul<<pkeyshift(execute_only_key));/* mark the rest of the keys as reserved and hence unavailable */for(i=(pkeys_total-os_reserved);i<pkeys_total;i++){
@@ -138,6 +142,17 @@ int pkey_initialize(void)pkey_uamor_mask&=~(0x3ul<<pkeyshift(i));}+if(unlikely((pkeys_total-os_reserved)<=execute_only_key)){+/*+*Insufficientnumberofkeystosupport+*executeonlykey.Markitunavailable.+*AnyAMR,UAMOR,IAMRbitsetfor+*thiskeyisirrelevantsincethiskey+*canneverbeallocated.+*/+execute_only_key=-1;+}+return0;}
@@ -148,8 +163,7 @@ void pkey_mm_init(struct mm_struct *mm)if(static_branch_likely(&pkey_disabled))return;mm_pkey_allocation_map(mm)=initial_allocation_mask;-/* -1 means unallocated or invalid */-mm->context.execute_only_pkey=-1;+mm->context.execute_only_pkey=execute_only_key;}staticinlineu64read_amr(void)
@@ -301,48 +315,7 @@ static inline bool pkey_allows_readwrite(int pkey)int__execute_only_pkey(structmm_struct*mm){-boolneed_to_set_mm_pkey=false;-intexecute_only_pkey=mm->context.execute_only_pkey;-intret;--/* Do we need to assign a pkey for mm's execute-only maps? */-if(execute_only_pkey==-1){-/* Go allocate one to use, which might fail */-execute_only_pkey=mm_pkey_alloc(mm);-if(execute_only_pkey<0)-return-1;-need_to_set_mm_pkey=true;-}--/*-*WedonotwanttogothroughtherelativelycostlydancetosetAMR-*ifwedonotneedto.Checkitfirstandassumethatifthe-*execute-onlypkeyisreadwrite-disabledthanwedonothavetosetit-*ourselves.-*/-if(!need_to_set_mm_pkey&&!pkey_allows_readwrite(execute_only_pkey))-returnexecute_only_pkey;--/*-*SetupAMRsothatitdeniesaccessforeverythingotherthan-*execution.-*/-ret=__arch_set_user_pkey_access(current,execute_only_pkey,-PKEY_DISABLE_ACCESS|-PKEY_DISABLE_WRITE);-/*-*IftheAMR-setoperationfailedsomehow,justreturn0and-*effectivelydisableexecute-onlysupport.-*/-if(ret){-mm_pkey_free(mm,execute_only_pkey);-return-1;-}--/* We got one, store it and use it from here on out */-if(need_to_set_mm_pkey)-mm->context.execute_only_pkey=execute_only_pkey;-returnexecute_only_pkey;+returnmm->context.execute_only_pkey;}staticinlineboolvma_is_pkey_exec_only(structvm_area_struct*vma)
Applications need the ability to associate an address-range with some
key and latter revert to its initial default key. Pkey-0 comes close to
providing this function but falls short, because the current
implementation disallows applications to explicitly associate pkey-0 to
the address range.
Lets make pkey-0 less special and treat it almost like any other key.
Thus it can be explicitly associated with any address range, and can be
freed. This gives the application more flexibility and power. The
ability to free pkey-0 must be used responsibily, since pkey-0 is
associated with almost all address-range by default.
Even with this change pkey-0 continues to be slightly more special
from the following point of view.
(a) it is implicitly allocated.
(b) it is the default key assigned to any address-range.
(c) its permissions cannot be modified by userspace.
NOTE: (c) is specific to powerpc only. pkey-0 is associated by default
with all pages including kernel pages, and pkeys are also active in
kernel mode. If any permission is denied on pkey-0, the kernel running
in the context of the application will be unable to operate.
Tested on powerpc.
cc: Thomas Gleixner <redacted>
cc: Dave Hansen <redacted>
cc: Michael Ellermen <mpe@ellerman.id.au>
cc: Ingo Molnar <mingo@kernel.org>
cc: Andrew Morton <akpm@linux-foundation.org>
cc: Thiago Jung Bauermann <redacted>
cc: Michal Such谩nek <msuchanek@suse.de
Signed-off-by: Ram Pai <redacted>
-----------------------------------------------------------------------
History:
v4: . introduced PKEY_0 macro. No bug fixes. Code
re-arrangement to save a few cycles.
v3: . Corrected a comment in arch_set_user_pkey_access(). .
Clarified the header, to capture the notion that pkey-0
permissions cannot be modified by userspace on powerpc.
-- comment from Thiago
v2: . mm_pkey_is_allocated() continued to treat pkey-0 special.
fixed it.
---
arch/powerpc/include/asm/pkeys.h | 29 +++++++++++++++++++++++------
arch/powerpc/mm/pkeys.c | 19 +++++++++----------
2 files changed, 32 insertions(+), 16 deletions(-)
@@ -13,7 +13,10 @@DECLARE_STATIC_KEY_TRUE(pkey_disabled);externintpkeys_total;/* total pkeys as per device tree */-externu32initial_allocation_mask;/* bits set for reserved keys */+externu32initial_allocation_mask;/* bits set for the initially allocated keys */+externu32reserved_allocation_mask;/* bits set for reserved keys */++#define PKEY_0 0#define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | VM_PKEY_BIT1 | VM_PKEY_BIT2 | \VM_PKEY_BIT3|VM_PKEY_BIT4)
@@ -83,15 +86,19 @@ static inline u16 pte_to_pkey_bits(u64 pteflags)#define __mm_pkey_is_allocated(mm, pkey) \(mm_pkey_allocation_map(mm)&pkey_alloc_mask(pkey))-#define __mm_pkey_is_reserved(pkey) (initial_allocation_mask & \+#define __mm_pkey_is_reserved(pkey) (reserved_allocation_mask & \pkey_alloc_mask(pkey))staticinlineboolmm_pkey_is_allocated(structmm_struct*mm,intpkey){-/* A reserved key is never considered as 'explicitly allocated' */-return((pkey<arch_max_pkey())&&-!__mm_pkey_is_reserved(pkey)&&-__mm_pkey_is_allocated(mm,pkey));+if(pkey<0||pkey>=arch_max_pkey())+returnfalse;++/* Reserved keys are never allocated. */+if(__mm_pkey_is_reserved(pkey))+returnfalse;++return__mm_pkey_is_allocated(mm,pkey);}/*
@@ -176,6 +183,16 @@ static inline int arch_set_user_pkey_access(struct task_struct *tsk, int pkey,{if(static_branch_likely(&pkey_disabled))return-EINVAL;++/*+*userspaceshouldnotchangepkey-0permissions.+*pkey-0isassociatedwitheverypageinthekernel.+*Ifuserspacedeniesanypermissiononpkey-0,the+*kernelcannotoperate.+*/+if(pkey==PKEY_0)+returninit_val?-EINVAL:0;+return__arch_set_user_pkey_access(tsk,pkey,init_val);}
@@ -14,7 +14,8 @@boolpkey_execute_disable_supported;intpkeys_total;/* Total pkeys as per device tree */boolpkeys_devtree_defined;/* pkey property exported by device tree */-u32initial_allocation_mask;/* Bits set for reserved keys */+u32initial_allocation_mask;/* Bits set for the initially allocated keys */+u32reserved_allocation_mask;/* Bits set for reserved keys */u64pkey_amr_mask;/* Bits in AMR not to be touched */u64pkey_iamr_mask;/* Bits in AMR not to be touched */u64pkey_uamor_mask;/* Bits in UMOR not to be touched */
@@ -121,26 +122,27 @@ int pkey_initialize(void)#elseos_reserved=0;#endif-initial_allocation_mask=(0x1<<0)|(0x1<<1)|-(0x1<<execute_only_key);+/* Bits are in LE format. */+reserved_allocation_mask=(0x1<<1)|(0x1<<execute_only_key);/* register mask is in BE format */pkey_amr_mask=~0x0ul;-pkey_amr_mask&=~(0x3ul<<pkeyshift(0));+pkey_amr_mask&=~(0x3ul<<pkeyshift(PKEY_0));pkey_iamr_mask=~0x0ul;-pkey_iamr_mask&=~(0x3ul<<pkeyshift(0));+pkey_iamr_mask&=~(0x3ul<<pkeyshift(PKEY_0));pkey_iamr_mask&=~(0x3ul<<pkeyshift(execute_only_key));pkey_uamor_mask=~0x0ul;-pkey_uamor_mask&=~(0x3ul<<pkeyshift(0));+pkey_uamor_mask&=~(0x3ul<<pkeyshift(PKEY_0));pkey_uamor_mask&=~(0x3ul<<pkeyshift(execute_only_key));/* mark the rest of the keys as reserved and hence unavailable */for(i=(pkeys_total-os_reserved);i<pkeys_total;i++){-initial_allocation_mask|=(0x1<<i);+reserved_allocation_mask|=(0x1<<i);pkey_uamor_mask&=~(0x3ul<<pkeyshift(i));}+initial_allocation_mask=reserved_allocation_mask|(0x1<<PKEY_0);if(unlikely((pkeys_total-os_reserved)<=execute_only_key)){/*
Only when the key is allocated, its permission are enabled.
Reviewed-by: Thiago Jung Bauermann <redacted>
Signed-off-by: Ram Pai <redacted>
---
tools/testing/selftests/powerpc/ptrace/core-pkey.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
The test case assumes execute-permissions of unallocated keys are
enabled by default.
Reviewed-by: Thiago Jung Bauermann <redacted>
Signed-off-by: Ram Pai <redacted>
---
.../testing/selftests/powerpc/ptrace/ptrace-pkey.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
From: Michael Ellerman <hidden> Date: 2018-07-24 13:59:57
On Tue, 2018-07-17 at 13:51:02 UTC, Ram Pai wrote:
Currently in a multithreaded application, a key allocated by one
thread is not usable by other threads. By "not usable" we mean that
other threads are unable to change the access permissions for that
key for themselves.
When a new key is allocated in one thread, the corresponding UAMOR
bits for that thread get enabled, however the UAMOR bits for that key
for all other threads remain disabled.
Other threads have no way to set permissions on the key, and the
current default permissions are that read/write is enabled for all
keys, which means the key has no effect for other threads. Although
that may be the desired behaviour in some circumstances, having all
threads able to control their permissions for the key is more
flexible.
The current behaviour also differs from the x86 behaviour, which is
problematic for users.
To fix this, enable the UAMOR bits for all keys, at process
creation (in start_thread(), ie exec time). Since the contents of
UAMOR are inherited at fork, all threads are capable of modifying the
permissions on any key.
This is technically an ABI break on powerpc, but pkey support is fairly
new on powerpc and not widely used, and this brings us into
line with x86.
Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem")
Cc: stable@vger.kernel.org # v4.16+
Tested-by: Florian Weimer <redacted>
Signed-off-by: Ram Pai <redacted>
[mpe: Reword some of the changelog]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>