From: Dave Hansen <dave.hansen@linux.intel.com> To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, Dave Hansen <dave.hansen@linux.intel.com>, shakeelb@google.com, stable@vger.kernel.org, linuxram@us.ibm.com, tglx@linutronix.de, dave.hansen@intel.com, mpe@ellerman.id.au, mingo@kernel.org, akpm@linux-foundation.org, shuah@kernel.org Subject: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC Date: Fri, 27 Apr 2018 10:45:32 -0700 [thread overview] Message-ID: <20180427174532.B20FFEA3@viggo.jf.intel.com> (raw) In-Reply-To: <20180427174527.0031016C@viggo.jf.intel.com> From: Dave Hansen <dave.hansen@linux.intel.com> I got a bug report that the following code (roughly) was causing a SIGSEGV: mprotect(ptr, size, PROT_EXEC); mprotect(ptr, size, PROT_NONE); mprotect(ptr, size, PROT_READ); *ptr = 100; The problem is hit when the mprotect(PROT_EXEC) is implicitly assigned a protection key to the VMA, and made that key ACCESS_DENY|WRITE_DENY. The PROT_NONE mprotect() failed to remove the protection key, and the PROT_NONE-> PROT_READ left the PTE usable, but the pkey still in place and left the memory inaccessible. To fix this, we ensure that we always "override" the pkee at mprotect() if the VMA does not have execute-only permissions, but the VMA has the execute-only pkey. We had a check for PROT_READ/WRITE, but it did not work for PROT_NONE. This entirely removes the PROT_* checks, which ensures that PROT_NONE now works. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Fixes: 62b5f7d013f ("mm/core, x86/mm/pkeys: Add execute-only protection keys support") Reported-by: Shakeel Butt <shakeelb@google.com> Cc: stable@vger.kernel.org Cc: Ram Pai <linuxram@us.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Ingo Molnar <mingo@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Shuah Khan <shuah@kernel.org> --- b/arch/x86/include/asm/pkeys.h | 12 +++++++++++- b/arch/x86/mm/pkeys.c | 21 +++++++++++---------- 2 files changed, 22 insertions(+), 11 deletions(-) diff -puN arch/x86/include/asm/pkeys.h~pkeys-abandon-exec-only-pkey-more-aggressively arch/x86/include/asm/pkeys.h --- a/arch/x86/include/asm/pkeys.h~pkeys-abandon-exec-only-pkey-more-aggressively 2018-04-26 10:42:18.971487371 -0700 +++ b/arch/x86/include/asm/pkeys.h 2018-04-26 10:42:18.977487371 -0700 @@ -2,6 +2,8 @@ #ifndef _ASM_X86_PKEYS_H #define _ASM_X86_PKEYS_H +#define ARCH_DEFAULT_PKEY 0 + #define arch_max_pkey() (boot_cpu_has(X86_FEATURE_OSPKE) ? 16 : 1) extern int arch_set_user_pkey_access(struct task_struct *tsk, int pkey, @@ -15,7 +17,7 @@ extern int __execute_only_pkey(struct mm static inline int execute_only_pkey(struct mm_struct *mm) { if (!boot_cpu_has(X86_FEATURE_OSPKE)) - return 0; + return ARCH_DEFAULT_PKEY; return __execute_only_pkey(mm); } @@ -56,6 +58,14 @@ bool mm_pkey_is_allocated(struct mm_stru return false; if (pkey >= arch_max_pkey()) return false; + /* + * The exec-only pkey is set in the allocation map, but + * is not available to any of the user interfaces like + * mprotect_pkey(). + */ + if (pkey == mm->context.execute_only_pkey) + return false; + return mm_pkey_allocation_map(mm) & (1U << pkey); } diff -puN arch/x86/mm/pkeys.c~pkeys-abandon-exec-only-pkey-more-aggressively arch/x86/mm/pkeys.c --- a/arch/x86/mm/pkeys.c~pkeys-abandon-exec-only-pkey-more-aggressively 2018-04-26 10:42:18.973487371 -0700 +++ b/arch/x86/mm/pkeys.c 2018-04-26 10:47:34.806486584 -0700 @@ -94,26 +94,27 @@ int __arch_override_mprotect_pkey(struct */ if (pkey != -1) return pkey; - /* - * Look for a protection-key-drive execute-only mapping - * which is now being given permissions that are not - * execute-only. Move it back to the default pkey. - */ - if (vma_is_pkey_exec_only(vma) && - (prot & (PROT_READ|PROT_WRITE))) { - return 0; - } + /* * The mapping is execute-only. Go try to get the * execute-only protection key. If we fail to do that, * fall through as if we do not have execute-only - * support. + * support in this mm. */ if (prot == PROT_EXEC) { pkey = execute_only_pkey(vma->vm_mm); if (pkey > 0) return pkey; + } else if (vma_is_pkey_exec_only(vma)) { + /* + * Protections are *not* PROT_EXEC, but the mapping + * is using the exec-only pkey. This mapping was + * PROT_EXEC and will no longer be. Move back to + * the default pkey. + */ + return ARCH_DEFAULT_PKEY; } + /* * This is a vanilla, non-pkey mprotect (or we failed to * setup execute-only), inherit the pkey from the VMA we _
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@linux.intel.com> To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org,Dave Hansen <dave.hansen@linux.intel.com>,shakeelb@google.com,stable@vger.kernel.org,linuxram@us.ibm.com,tglx@linutronix.de,dave.hansen@intel.com,mpe@ellerman.id.au,mingo@kernel.org,akpm@linux-foundation.org,shuah@kernel.org Subject: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC Date: Fri, 27 Apr 2018 10:45:32 -0700 [thread overview] Message-ID: <20180427174532.B20FFEA3@viggo.jf.intel.com> (raw) In-Reply-To: <20180427174527.0031016C@viggo.jf.intel.com> From: Dave Hansen <dave.hansen@linux.intel.com> I got a bug report that the following code (roughly) was causing a SIGSEGV: mprotect(ptr, size, PROT_EXEC); mprotect(ptr, size, PROT_NONE); mprotect(ptr, size, PROT_READ); *ptr = 100; The problem is hit when the mprotect(PROT_EXEC) is implicitly assigned a protection key to the VMA, and made that key ACCESS_DENY|WRITE_DENY. The PROT_NONE mprotect() failed to remove the protection key, and the PROT_NONE-> PROT_READ left the PTE usable, but the pkey still in place and left the memory inaccessible. To fix this, we ensure that we always "override" the pkee at mprotect() if the VMA does not have execute-only permissions, but the VMA has the execute-only pkey. We had a check for PROT_READ/WRITE, but it did not work for PROT_NONE. This entirely removes the PROT_* checks, which ensures that PROT_NONE now works. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Fixes: 62b5f7d013f ("mm/core, x86/mm/pkeys: Add execute-only protection keys support") Reported-by: Shakeel Butt <shakeelb@google.com> Cc: stable@vger.kernel.org Cc: Ram Pai <linuxram@us.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Ingo Molnar <mingo@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Shuah Khan <shuah@kernel.org> --- b/arch/x86/include/asm/pkeys.h | 12 +++++++++++- b/arch/x86/mm/pkeys.c | 21 +++++++++++---------- 2 files changed, 22 insertions(+), 11 deletions(-) diff -puN arch/x86/include/asm/pkeys.h~pkeys-abandon-exec-only-pkey-more-aggressively arch/x86/include/asm/pkeys.h --- a/arch/x86/include/asm/pkeys.h~pkeys-abandon-exec-only-pkey-more-aggressively 2018-04-26 10:42:18.971487371 -0700 +++ b/arch/x86/include/asm/pkeys.h 2018-04-26 10:42:18.977487371 -0700 @@ -2,6 +2,8 @@ #ifndef _ASM_X86_PKEYS_H #define _ASM_X86_PKEYS_H +#define ARCH_DEFAULT_PKEY 0 + #define arch_max_pkey() (boot_cpu_has(X86_FEATURE_OSPKE) ? 16 : 1) extern int arch_set_user_pkey_access(struct task_struct *tsk, int pkey, @@ -15,7 +17,7 @@ extern int __execute_only_pkey(struct mm static inline int execute_only_pkey(struct mm_struct *mm) { if (!boot_cpu_has(X86_FEATURE_OSPKE)) - return 0; + return ARCH_DEFAULT_PKEY; return __execute_only_pkey(mm); } @@ -56,6 +58,14 @@ bool mm_pkey_is_allocated(struct mm_stru return false; if (pkey >= arch_max_pkey()) return false; + /* + * The exec-only pkey is set in the allocation map, but + * is not available to any of the user interfaces like + * mprotect_pkey(). + */ + if (pkey == mm->context.execute_only_pkey) + return false; + return mm_pkey_allocation_map(mm) & (1U << pkey); } diff -puN arch/x86/mm/pkeys.c~pkeys-abandon-exec-only-pkey-more-aggressively arch/x86/mm/pkeys.c --- a/arch/x86/mm/pkeys.c~pkeys-abandon-exec-only-pkey-more-aggressively 2018-04-26 10:42:18.973487371 -0700 +++ b/arch/x86/mm/pkeys.c 2018-04-26 10:47:34.806486584 -0700 @@ -94,26 +94,27 @@ int __arch_override_mprotect_pkey(struct */ if (pkey != -1) return pkey; - /* - * Look for a protection-key-drive execute-only mapping - * which is now being given permissions that are not - * execute-only. Move it back to the default pkey. - */ - if (vma_is_pkey_exec_only(vma) && - (prot & (PROT_READ|PROT_WRITE))) { - return 0; - } + /* * The mapping is execute-only. Go try to get the * execute-only protection key. If we fail to do that, * fall through as if we do not have execute-only - * support. + * support in this mm. */ if (prot == PROT_EXEC) { pkey = execute_only_pkey(vma->vm_mm); if (pkey > 0) return pkey; + } else if (vma_is_pkey_exec_only(vma)) { + /* + * Protections are *not* PROT_EXEC, but the mapping + * is using the exec-only pkey. This mapping was + * PROT_EXEC and will no longer be. Move back to + * the default pkey. + */ + return ARCH_DEFAULT_PKEY; } + /* * This is a vanilla, non-pkey mprotect (or we failed to * setup execute-only), inherit the pkey from the VMA we _
next prev parent reply other threads:[~2018-04-27 17:51 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-27 17:45 [PATCH 0/9] [v3] x86, pkeys: two protection keys bug fixes Dave Hansen 2018-04-27 17:45 ` [PATCH 1/9] x86, pkeys: do not special case protection key 0 Dave Hansen 2018-04-27 17:45 ` Dave Hansen 2018-04-27 17:45 ` [PATCH 2/9] x86, pkeys, selftests: save off 'prot' for allocations Dave Hansen 2018-04-27 17:45 ` [PATCH 3/9] x86, pkeys, selftests: add a test for pkey 0 Dave Hansen 2018-04-27 17:45 ` Dave Hansen [this message] 2018-04-27 17:45 ` [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC Dave Hansen 2018-04-27 17:45 ` [PATCH 5/9] x86, pkeys, selftests: fix pointer math Dave Hansen 2018-04-27 17:45 ` [PATCH 6/9] x86, pkeys, selftests: fix pkey exhaustion test off-by-one Dave Hansen 2018-04-27 17:45 ` [PATCH 7/9] x86, pkeys, selftests: factor out "instruction page" Dave Hansen 2018-04-27 17:45 ` [PATCH 8/9] x86, pkeys, selftests: add allow faults on unknown keys Dave Hansen 2018-04-27 17:45 ` [PATCH 9/9] x86, pkeys, selftests: add PROT_EXEC test Dave Hansen 2018-04-28 7:05 ` [PATCH 0/9] [v3] x86, pkeys: two protection keys bug fixes Ingo Molnar 2018-04-28 7:15 ` Ingo Molnar 2018-04-28 8:29 ` Ingo Molnar 2018-04-30 15:30 ` Dave Hansen 2018-04-30 16:28 ` Ram Pai 2018-05-08 22:49 ` Dave Hansen -- strict thread matches above, loose matches on Subject: below -- 2018-03-26 17:27 [PATCH 0/9] [v2] " Dave Hansen 2018-03-26 17:27 ` [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC Dave Hansen 2018-04-07 0:09 ` Ram Pai 2018-04-07 0:47 ` Dave Hansen 2018-04-07 1:09 ` Ram Pai 2018-04-26 17:57 ` Dave Hansen 2018-04-30 7:51 ` Ram Pai 2018-04-30 16:36 ` Dave Hansen 2018-04-25 22:10 ` Shakeel Butt 2018-04-26 8:55 ` Thomas Gleixner 2018-04-26 18:17 ` Dave Hansen 2018-03-23 18:09 [PATCH 0/9] x86, pkeys: two protection keys bug fixes Dave Hansen 2018-03-23 18:09 ` [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC Dave Hansen 2018-03-23 19:15 ` Shakeel Butt 2018-03-23 19:23 ` Dave Hansen 2018-03-23 19:27 ` Shakeel Butt 2018-03-23 19:29 ` Dave Hansen 2018-03-23 19:38 ` Thomas Gleixner 2018-03-23 19:45 ` Thomas Gleixner 2018-03-23 19:48 ` Dave Hansen
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=20180427174532.B20FFEA3@viggo.jf.intel.com \ --to=dave.hansen@linux.intel.com \ --cc=akpm@linux-foundation.org \ --cc=dave.hansen@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linuxram@us.ibm.com \ --cc=mingo@kernel.org \ --cc=mpe@ellerman.id.au \ --cc=shakeelb@google.com \ --cc=shuah@kernel.org \ --cc=stable@vger.kernel.org \ --cc=tglx@linutronix.de \ /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.