From: Ram Pai <linuxram@us.ibm.com> To: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org Cc: benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, khandual@linux.vnet.ibm.com, aneesh.kumar@linux.vnet.ibm.com, bsingharora@gmail.com, dave.hansen@intel.com, hbabu@us.ibm.com, linuxram@us.ibm.com, arnd@arndb.de, akpm@linux-foundation.org, corbet@lwn.net, mingo@redhat.com, mhocko@kernel.org Subject: [RFC v6 62/62] Documentation/vm: PowerPC specific updates to memory protection keys Date: Sat, 15 Jul 2017 20:57:04 -0700 [thread overview] Message-ID: <1500177424-13695-63-git-send-email-linuxram@us.ibm.com> (raw) In-Reply-To: <1500177424-13695-1-git-send-email-linuxram@us.ibm.com> Add documentation updates that capture PowerPC specific changes. Signed-off-by: Ram Pai <linuxram@us.ibm.com> --- Documentation/vm/protection-keys.txt | 90 ++++++++++++++++++++++++--------- 1 files changed, 65 insertions(+), 25 deletions(-) diff --git a/Documentation/vm/protection-keys.txt b/Documentation/vm/protection-keys.txt index b643045..9330105 100644 --- a/Documentation/vm/protection-keys.txt +++ b/Documentation/vm/protection-keys.txt @@ -1,22 +1,45 @@ -Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature -which will be found on future Intel CPUs. - -Memory Protection Keys provides a mechanism for enforcing page-based -protections, but without requiring modification of the page tables -when an application changes protection domains. It works by -dedicating 4 previously ignored bits in each page table entry to a -"protection key", giving 16 possible keys. - -There is also a new user-accessible register (PKRU) with two separate -bits (Access Disable and Write Disable) for each key. Being a CPU -register, PKRU is inherently thread-local, potentially giving each -thread a different set of protections from every other thread. - -There are two new instructions (RDPKRU/WRPKRU) for reading and writing -to the new register. The feature is only available in 64-bit mode, -even though there is theoretically space in the PAE PTEs. These -permissions are enforced on data access only and have no effect on -instruction fetches. +Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature found on +future Intel CPUs and on PowerPC 7 and higher CPUs. + +Memory Protection Keys provide a mechanism for enforcing page-based +protections, but without requiring modification of the page tables when an +application changes protection domains. + +It works by dedicating bits in each page table entry to a "protection key". +There is also a user-accessible register with two separate bits for each +key. Being a CPU register, the user-accessible register is inherently +thread-local, potentially giving each thread a different set of protections +from every other thread. + +On Intel: + + Four previously bits are used the page table entry giving 16 possible keys. + + The user accessible register(PKRU) has a bit each per key to disable + access and to disable write. + + The feature is only available in 64-bit mode, even though there is + theoretically space in the PAE PTEs. These permissions are enforced on + data access only and have no effect on instruction fetches. + +On PowerPC: + + Five bits in the page table entry are used giving 32 possible keys. + This support is currently for Hash Page Table mode only. + + The user accessible register(AMR) has a bit each per key to disable + read and write. Access disable can be achieved by disabling + read and write. + + 'mtspr 0xd, mem' reads the AMR register + 'mfspr mem, 0xd' writes into the AMR register. + + Execution can be disabled by allocating a key with execute-disabled + permission. The execute-permissions on the key; however, cannot be + changed through a user accessible register. The CPU will not allow + execution of instruction in pages that are associated with + execute-disabled key. + =========================== Syscalls =========================== @@ -28,9 +51,9 @@ There are 3 system calls which directly interact with pkeys: unsigned long prot, int pkey); Before a pkey can be used, it must first be allocated with -pkey_alloc(). An application calls the WRPKRU instruction +pkey_alloc(). An application calls the WRPKRU/AMR instruction directly in order to change access permissions to memory covered -with a key. In this example WRPKRU is wrapped by a C function +with a key. In this example WRPKRU/AMR is wrapped by a C function called pkey_set(). int real_prot = PROT_READ|PROT_WRITE; @@ -52,11 +75,11 @@ is no longer in use: munmap(ptr, PAGE_SIZE); pkey_free(pkey); -(Note: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions. +(Note: pkey_set() is a wrapper for the RDPKRU,WRPKRU or AMR instructions. An example implementation can be found in - tools/testing/selftests/x86/protection_keys.c) + tools/testing/selftests/vm/protection_keys.c) -=========================== Behavior =========================== +=========================== Behavior ================================= The kernel attempts to make protection keys consistent with the behavior of a plain mprotect(). For instance if you do this: @@ -66,7 +89,7 @@ behavior of a plain mprotect(). For instance if you do this: you can expect the same effects with protection keys when doing this: - pkey = pkey_alloc(0, PKEY_DISABLE_WRITE | PKEY_DISABLE_READ); + pkey = pkey_alloc(0, PKEY_DISABLE_ACCESS); pkey_mprotect(ptr, size, PROT_READ|PROT_WRITE, pkey); something(ptr); @@ -83,3 +106,20 @@ with a read(): The kernel will send a SIGSEGV in both cases, but si_code will be set to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when the plain mprotect() permissions are violated. + + +==================================================================== + Semantic differences + +The following semantic differences exist between x86 and power. + +a) powerpc *also* allows creation of a key with execute-disabled. + The following is allowed on powerpc. + pkey = pkey_alloc(0, PKEY_DISABLE_EXECUTE); + +b) changing the permission bits of a key from a signal handler does not + persist on x86. The PKRU specific fpregs entry needs to be modified + for it to persist. On powerpc the permission bits of the key can be + modified by programming the AMR register from the signal handler. + The changes persist across signal boundaries. +===================================================================== -- 1.7.1
WARNING: multiple messages have this Message-ID (diff)
From: Ram Pai <linuxram@us.ibm.com> To: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org Cc: benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, khandual@linux.vnet.ibm.com, aneesh.kumar@linux.vnet.ibm.com, bsingharora@gmail.com, dave.hansen@intel.com, hbabu@us.ibm.com, linuxram@us.ibm.com, arnd@arndb.de, akpm@linux-foundation.org, corbet@lwn.net, mingo@redhat.com, mhocko@kernel.org Subject: [RFC v6 62/62] Documentation/vm: PowerPC specific updates to memory protection keys Date: Sat, 15 Jul 2017 20:57:04 -0700 [thread overview] Message-ID: <1500177424-13695-63-git-send-email-linuxram@us.ibm.com> (raw) In-Reply-To: <1500177424-13695-1-git-send-email-linuxram@us.ibm.com> Add documentation updates that capture PowerPC specific changes. Signed-off-by: Ram Pai <linuxram@us.ibm.com> --- Documentation/vm/protection-keys.txt | 90 ++++++++++++++++++++++++--------- 1 files changed, 65 insertions(+), 25 deletions(-) diff --git a/Documentation/vm/protection-keys.txt b/Documentation/vm/protection-keys.txt index b643045..9330105 100644 --- a/Documentation/vm/protection-keys.txt +++ b/Documentation/vm/protection-keys.txt @@ -1,22 +1,45 @@ -Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature -which will be found on future Intel CPUs. - -Memory Protection Keys provides a mechanism for enforcing page-based -protections, but without requiring modification of the page tables -when an application changes protection domains. It works by -dedicating 4 previously ignored bits in each page table entry to a -"protection key", giving 16 possible keys. - -There is also a new user-accessible register (PKRU) with two separate -bits (Access Disable and Write Disable) for each key. Being a CPU -register, PKRU is inherently thread-local, potentially giving each -thread a different set of protections from every other thread. - -There are two new instructions (RDPKRU/WRPKRU) for reading and writing -to the new register. The feature is only available in 64-bit mode, -even though there is theoretically space in the PAE PTEs. These -permissions are enforced on data access only and have no effect on -instruction fetches. +Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature found on +future Intel CPUs and on PowerPC 7 and higher CPUs. + +Memory Protection Keys provide a mechanism for enforcing page-based +protections, but without requiring modification of the page tables when an +application changes protection domains. + +It works by dedicating bits in each page table entry to a "protection key". +There is also a user-accessible register with two separate bits for each +key. Being a CPU register, the user-accessible register is inherently +thread-local, potentially giving each thread a different set of protections +from every other thread. + +On Intel: + + Four previously bits are used the page table entry giving 16 possible keys. + + The user accessible register(PKRU) has a bit each per key to disable + access and to disable write. + + The feature is only available in 64-bit mode, even though there is + theoretically space in the PAE PTEs. These permissions are enforced on + data access only and have no effect on instruction fetches. + +On PowerPC: + + Five bits in the page table entry are used giving 32 possible keys. + This support is currently for Hash Page Table mode only. + + The user accessible register(AMR) has a bit each per key to disable + read and write. Access disable can be achieved by disabling + read and write. + + 'mtspr 0xd, mem' reads the AMR register + 'mfspr mem, 0xd' writes into the AMR register. + + Execution can be disabled by allocating a key with execute-disabled + permission. The execute-permissions on the key; however, cannot be + changed through a user accessible register. The CPU will not allow + execution of instruction in pages that are associated with + execute-disabled key. + =========================== Syscalls =========================== @@ -28,9 +51,9 @@ There are 3 system calls which directly interact with pkeys: unsigned long prot, int pkey); Before a pkey can be used, it must first be allocated with -pkey_alloc(). An application calls the WRPKRU instruction +pkey_alloc(). An application calls the WRPKRU/AMR instruction directly in order to change access permissions to memory covered -with a key. In this example WRPKRU is wrapped by a C function +with a key. In this example WRPKRU/AMR is wrapped by a C function called pkey_set(). int real_prot = PROT_READ|PROT_WRITE; @@ -52,11 +75,11 @@ is no longer in use: munmap(ptr, PAGE_SIZE); pkey_free(pkey); -(Note: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions. +(Note: pkey_set() is a wrapper for the RDPKRU,WRPKRU or AMR instructions. An example implementation can be found in - tools/testing/selftests/x86/protection_keys.c) + tools/testing/selftests/vm/protection_keys.c) -=========================== Behavior =========================== +=========================== Behavior ================================= The kernel attempts to make protection keys consistent with the behavior of a plain mprotect(). For instance if you do this: @@ -66,7 +89,7 @@ behavior of a plain mprotect(). For instance if you do this: you can expect the same effects with protection keys when doing this: - pkey = pkey_alloc(0, PKEY_DISABLE_WRITE | PKEY_DISABLE_READ); + pkey = pkey_alloc(0, PKEY_DISABLE_ACCESS); pkey_mprotect(ptr, size, PROT_READ|PROT_WRITE, pkey); something(ptr); @@ -83,3 +106,20 @@ with a read(): The kernel will send a SIGSEGV in both cases, but si_code will be set to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when the plain mprotect() permissions are violated. + + +==================================================================== + Semantic differences + +The following semantic differences exist between x86 and power. + +a) powerpc *also* allows creation of a key with execute-disabled. + The following is allowed on powerpc. + pkey = pkey_alloc(0, PKEY_DISABLE_EXECUTE); + +b) changing the permission bits of a key from a signal handler does not + persist on x86. The PKRU specific fpregs entry needs to be modified + for it to persist. On powerpc the permission bits of the key can be + modified by programming the AMR register from the signal handler. + The changes persist across signal boundaries. +===================================================================== -- 1.7.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-07-16 4:00 UTC|newest] Thread overview: 230+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-07-16 3:56 [RFC v6 00/62] powerpc: Memory Protection Keys Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 01/62] powerpc: Free up four 64K PTE bits in 4K backed HPTE pages Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-20 5:51 ` Aneesh Kumar K.V 2017-07-20 5:51 ` Aneesh Kumar K.V 2017-07-20 5:51 ` Aneesh Kumar K.V 2017-07-20 5:51 ` Aneesh Kumar K.V 2017-07-20 22:03 ` Ram Pai 2017-07-20 22:03 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 02/62] powerpc: Free up four 64K PTE bits in 64K " Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-20 5:53 ` Aneesh Kumar K.V 2017-07-20 5:53 ` Aneesh Kumar K.V 2017-07-20 5:53 ` Aneesh Kumar K.V 2017-07-20 5:53 ` Aneesh Kumar K.V 2017-07-16 3:56 ` [RFC v6 03/62] powerpc: introduce pte_set_hash_slot() helper Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-20 5:56 ` Aneesh Kumar K.V 2017-07-20 5:56 ` Aneesh Kumar K.V 2017-07-20 5:56 ` Aneesh Kumar K.V 2017-07-20 5:56 ` Aneesh Kumar K.V 2017-07-16 3:56 ` [RFC v6 04/62] powerpc: introduce pte_get_hash_gslot() helper Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-20 5:57 ` Aneesh Kumar K.V 2017-07-20 5:57 ` Aneesh Kumar K.V 2017-07-20 5:57 ` Aneesh Kumar K.V 2017-07-20 5:57 ` Aneesh Kumar K.V 2017-07-16 3:56 ` [RFC v6 05/62] powerpc: capture the PTE format changes in the dump pte report Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-20 5:56 ` Aneesh Kumar K.V 2017-07-20 5:56 ` Aneesh Kumar K.V 2017-07-20 5:56 ` Aneesh Kumar K.V 2017-07-20 5:56 ` Aneesh Kumar K.V 2017-07-16 3:56 ` [RFC v6 06/62] powerpc: use helper functions in __hash_page_64K() for 64K PTE Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-20 5:58 ` Aneesh Kumar K.V 2017-07-20 5:58 ` Aneesh Kumar K.V 2017-07-20 5:58 ` Aneesh Kumar K.V 2017-07-20 5:58 ` Aneesh Kumar K.V 2017-07-16 3:56 ` [RFC v6 07/62] powerpc: use helper functions in __hash_page_huge() " Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-20 5:58 ` Aneesh Kumar K.V 2017-07-20 5:58 ` Aneesh Kumar K.V 2017-07-20 5:58 ` Aneesh Kumar K.V 2017-07-20 5:58 ` Aneesh Kumar K.V 2017-07-16 3:56 ` [RFC v6 08/62] powerpc: use helper functions in __hash_page_4K() " Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 09/62] powerpc: use helper functions in __hash_page_4K() for 4K PTE Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 10/62] powerpc: use helper functions in flush_hash_page() Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 11/62] powerpc: initial pkey plumbing Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-20 6:04 ` Aneesh Kumar K.V 2017-07-20 6:04 ` Aneesh Kumar K.V 2017-07-20 6:04 ` Aneesh Kumar K.V 2017-07-20 6:04 ` Aneesh Kumar K.V 2017-07-20 22:11 ` Ram Pai 2017-07-20 22:11 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 12/62] mm: introduce an additional vma bit for powerpc pkey Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 13/62] powerpc: track allocation status of all pkeys Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-27 14:01 ` Thiago Jung Bauermann 2017-07-27 14:01 ` Thiago Jung Bauermann 2017-07-29 22:43 ` Ram Pai 2017-07-29 22:43 ` Ram Pai 2017-07-29 22:43 ` Ram Pai 2017-07-31 18:15 ` Thiago Jung Bauermann 2017-07-31 18:15 ` Thiago Jung Bauermann 2017-07-16 3:56 ` [RFC v6 14/62] powerpc: helper function to read,write AMR,IAMR,UAMOR registers Ram Pai 2017-07-16 3:56 ` [RFC v6 14/62] powerpc: helper function to read, write AMR, IAMR, UAMOR registers Ram Pai 2017-07-16 3:56 ` [RFC v6 14/62] powerpc: helper function to read,write AMR,IAMR,UAMOR registers Ram Pai 2017-07-16 3:56 ` [RFC v6 15/62] powerpc: helper functions to initialize AMR, IAMR and UMOR registers Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-27 20:40 ` Thiago Jung Bauermann 2017-07-27 20:40 ` Thiago Jung Bauermann 2017-07-30 0:38 ` Ram Pai 2017-07-30 0:38 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 16/62] powerpc: cleaup AMR,iAMR when a key is allocated or freed Ram Pai 2017-07-16 3:56 ` [RFC v6 16/62] powerpc: cleaup AMR, iAMR " Ram Pai 2017-07-16 3:56 ` [RFC v6 16/62] powerpc: cleaup AMR,iAMR " Ram Pai 2017-07-16 3:56 ` [RFC v6 17/62] powerpc: implementation for arch_set_user_pkey_access() Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-27 14:15 ` Thiago Jung Bauermann 2017-07-27 14:15 ` Thiago Jung Bauermann 2017-07-29 22:59 ` Ram Pai 2017-07-29 22:59 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 18/62] powerpc: sys_pkey_alloc() and sys_pkey_free() system calls Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 19/62] powerpc: ability to create execute-disabled pkeys Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-27 14:54 ` Thiago Jung Bauermann 2017-07-27 14:54 ` Thiago Jung Bauermann 2017-07-27 15:34 ` Thiago Jung Bauermann 2017-07-27 15:34 ` Thiago Jung Bauermann 2017-07-29 23:24 ` Ram Pai 2017-07-29 23:24 ` Ram Pai 2017-07-31 12:59 ` Michael Ellerman 2017-07-31 12:59 ` Michael Ellerman 2017-07-16 3:56 ` [RFC v6 20/62] powerpc: store and restore the pkey state across context switches Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-27 17:32 ` Thiago Jung Bauermann 2017-07-27 17:32 ` Thiago Jung Bauermann 2017-07-29 23:31 ` Ram Pai 2017-07-29 23:31 ` Ram Pai 2017-07-31 13:00 ` Michael Ellerman 2017-07-31 13:00 ` Michael Ellerman 2017-07-16 3:56 ` [RFC v6 21/62] powerpc: introduce execute-only pkey Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-28 22:17 ` Thiago Jung Bauermann 2017-07-28 22:17 ` Thiago Jung Bauermann 2017-07-30 0:51 ` Ram Pai 2017-07-30 0:51 ` Ram Pai 2017-07-31 16:19 ` Thiago Jung Bauermann 2017-07-31 16:19 ` Thiago Jung Bauermann 2017-08-01 6:46 ` Michael Ellerman 2017-08-01 6:46 ` Michael Ellerman 2017-08-01 16:14 ` Thiago Jung Bauermann 2017-08-01 16:14 ` Thiago Jung Bauermann 2017-08-01 16:14 ` Thiago Jung Bauermann 2017-08-02 9:40 ` Michael Ellerman 2017-08-02 9:40 ` Michael Ellerman [not found] ` <20170817233555.GC5427@ram.oc3035372033.ibm.com> 2017-08-17 23:42 ` Ram Pai 2017-08-17 23:42 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 22/62] powerpc: ability to associate pkey to a vma Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 23/62] powerpc: implementation for arch_override_mprotect_pkey() Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 24/62] powerpc: map vma key-protection bits to pte key bits Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 25/62] powerpc: sys_pkey_mprotect() system call Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 26/62] powerpc: Program HPTE key protection bits Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-20 6:28 ` Aneesh Kumar K.V 2017-07-20 6:28 ` Aneesh Kumar K.V 2017-07-20 6:28 ` Aneesh Kumar K.V 2017-07-20 6:28 ` Aneesh Kumar K.V 2017-07-16 3:56 ` [RFC v6 27/62] powerpc: helper to validate key-access permissions of a pte Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-20 6:42 ` Aneesh Kumar K.V 2017-07-20 6:42 ` Aneesh Kumar K.V 2017-07-20 6:42 ` Aneesh Kumar K.V 2017-07-20 6:42 ` Aneesh Kumar K.V 2017-07-20 22:15 ` Ram Pai 2017-07-20 22:15 ` Ram Pai 2017-07-21 6:51 ` Aneesh Kumar K.V 2017-07-21 6:51 ` Aneesh Kumar K.V 2017-07-21 16:42 ` Ram Pai 2017-07-21 16:42 ` Ram Pai 2017-07-28 21:00 ` Thiago Jung Bauermann 2017-07-28 21:00 ` Thiago Jung Bauermann 2017-07-30 0:39 ` Ram Pai 2017-07-30 0:39 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 28/62] powerpc: check key protection for user page access Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 29/62] powerpc: Macro the mask used for checking DSI exception Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 30/62] powerpc: implementation for arch_vma_access_permitted() Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 31/62] powerpc: Handle exceptions caused by pkey violation Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 32/62] powerpc: capture AMR register content on " Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 33/62] powerpc: introduce get_pte_pkey() helper Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 34/62] powerpc: capture the violated protection key on fault Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 35/62] powerpc: Deliver SEGV signal on pkey violation Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-08-19 19:09 ` Eric W. Biederman 2017-08-19 19:09 ` Eric W. Biederman 2017-08-22 18:06 ` Ram Pai 2017-08-22 18:06 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 36/62] mm: introduce arch_pkeys_enabled() Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 37/62] x86: implementation for arch_pkeys_enabled() Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 38/62] powerpc: " Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 39/62] mm: display pkey in smaps if arch_pkeys_enabled() is true Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 40/62] x86: delete arch_show_smap() Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 41/62] selftest/x86: Move protecton key selftest to arch neutral directory Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 42/62] selftest/vm: rename all references to pkru to a generic name Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 43/62] selftest/vm: move generic definitions to header file Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 44/62] selftest/vm: typecast the pkey register Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 45/62] selftest/vm: generics function to handle shadow key register Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 46/62] selftest/vm: fix the wrong assert in pkey_disable_set() Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 47/62] selftest/vm: fixed bugs in pkey_disable_clear() Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 48/62] selftest/vm: clear the bits in shadow reg when a pkey is freed Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 49/62] selftest/vm: fix alloc_random_pkey() to make it really random Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 50/62] selftest/vm: introduce two arch independent abstraction Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 51/62] selftest/vm: pkey register should match shadow pkey Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 52/62] selftest/vm: generic cleanup Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 53/62] selftest/vm: powerpc implementation for generic abstraction Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 54/62] selftest/vm: fix an assertion in test_pkey_alloc_exhaust() Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 55/62] selftest/vm: associate key on a mapped page and detect access violation Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 56/62] selftest/vm: detect no key violation on a freed key Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:56 ` [RFC v6 57/62] selftest/vm: associate key on a mapped page and detect write violation Ram Pai 2017-07-16 3:56 ` Ram Pai 2017-07-16 3:57 ` [RFC v6 58/62] selftest/vm: detect no write key-violation on a freed key Ram Pai 2017-07-16 3:57 ` Ram Pai 2017-07-16 3:57 ` [RFC v6 59/62] selftest/vm: detect write violation on a mapped access-denied-key page Ram Pai 2017-07-16 3:57 ` Ram Pai 2017-07-16 3:57 ` [RFC v6 60/62] selftest/vm: sub-page allocator Ram Pai 2017-07-16 3:57 ` Ram Pai 2017-07-16 3:57 ` [RFC v6 61/62] Documentation/x86: Move protecton key documentation to arch neutral directory Ram Pai 2017-07-16 3:57 ` Ram Pai 2017-07-16 3:57 ` Ram Pai [this message] 2017-07-16 3:57 ` [RFC v6 62/62] Documentation/vm: PowerPC specific updates to memory protection keys Ram Pai
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1500177424-13695-63-git-send-email-linuxram@us.ibm.com \ --to=linuxram@us.ibm.com \ --cc=akpm@linux-foundation.org \ --cc=aneesh.kumar@linux.vnet.ibm.com \ --cc=arnd@arndb.de \ --cc=benh@kernel.crashing.org \ --cc=bsingharora@gmail.com \ --cc=corbet@lwn.net \ --cc=dave.hansen@intel.com \ --cc=hbabu@us.ibm.com \ --cc=khandual@linux.vnet.ibm.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mhocko@kernel.org \ --cc=mingo@redhat.com \ --cc=mpe@ellerman.id.au \ --cc=paulus@samba.org \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.