From patchwork Mon May 21 06:41:29 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 10414021 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 85AE0600CC for ; Mon, 21 May 2018 06:42:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7680E28782 for ; Mon, 21 May 2018 06:42:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6AD2428795; Mon, 21 May 2018 06:42:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9709F28782 for ; Mon, 21 May 2018 06:42:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 813F46B000C; Mon, 21 May 2018 02:42:29 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 7E9946B000D; Mon, 21 May 2018 02:42:29 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DD056B000E; Mon, 21 May 2018 02:42:29 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pf0-f197.google.com (mail-pf0-f197.google.com [209.85.192.197]) by kanga.kvack.org (Postfix) with ESMTP id 28A046B000C for ; Mon, 21 May 2018 02:42:29 -0400 (EDT) Received: by mail-pf0-f197.google.com with SMTP id d20-v6so8691384pfn.16 for ; Sun, 20 May 2018 23:42:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:subject:to:cc:from:date :message-id:mime-version:content-transfer-encoding; bh=ahVpKZQ6EzKhGs7eOdhKx+EjTsEWJ43TNAFpov5jJtE=; b=E7vLWM9UZ6T0ojWdQ9f1yGwf9eo6HjHwIHFVebq6JIdlihs9g3MwPugyorVouRoeZ7 LdL97iy01OaczHBqsxIFGuTGW8jdhMyINkR5YAdoQWm1PsxTRIGcKvJIWgFJXaEK+ifg AIeOTewmO3+dOWubNcK5wBn3WWKXuNtAaCjvonPFifbAeaOZVKZkEAgny/gWV0LS6vUp K1eRUsATSV5LGfvL2zfD7HeppYQGc7YwHW4yRwgCIDuwOnZqdNuF22g+RJ+jJDWz9OhR e3pWQN4IwV1+pvyVBv1kPv+xjFMu8sR0YSF9of7rs5OsUCfOJ0awVHpA1NbwLmI+ppcB DVbA== X-Gm-Message-State: ALKqPwcR9r/D63Z6QbUeOEWUEB+2b/5ijNEVj7oZxPSyHn5bxk0yRPDP MUKlcRe0ZWbRNa9Oe8GbbHMCHiEq23DZLJJY3ah+VDdLsfiz80pPMf1WwThkKebCbjaHrr6fmip PT4eZhqSccncPherMoLep5cBzwHLzDrEAmNLM6L95DIJ6WKMbDzfTVlFxKiEdrg0= X-Received: by 2002:a17:902:a4:: with SMTP id a33-v6mr18999402pla.346.1526884948778; Sun, 20 May 2018 23:42:28 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoMLSnSulam8o+qnpNQnNtC3oPTMbEBfT4a8dWkhPuHQNkwku+z9I0U7rPQIseqCq8EOeHi X-Received: by 2002:a17:902:a4:: with SMTP id a33-v6mr18999366pla.346.1526884948025; Sun, 20 May 2018 23:42:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526884948; cv=none; d=google.com; s=arc-20160816; b=0qDbPoU6xr0o8SWhtzIUp+y7CjHepxjizGewPdYVUilPxzXAzL8fpnXAWke+ZYeyFG 2hc+RFTtiiP85yxH6ql5BvQwsjpZzNkESnlYUvaMT/EznufRJ++2OV+TB51ESs/JtpmV 4x9xYeoYFzhJwQ0keChcarzbdPd3VY7wggACWn09+OAL4PR4H1HCLvkpm1//nAI8vB9z cmeG3BRqxS5iwZGmCoe7v4qoaJcAncZMp9qY0E2KAo6DD/m4/YW6Gf9tNE9tLobwwEtM 3mJqKY+HEiK0SFdvn28wRLj+NndHQzEPyPAZxHJAPYUoQPK2FVeyHRuZH7ZNPLi/9uyW rg8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:message-id:date:from:cc:to :subject:dkim-signature:arc-authentication-results; bh=ahVpKZQ6EzKhGs7eOdhKx+EjTsEWJ43TNAFpov5jJtE=; b=LdP9F1qxSS9qJY9qOdQKSrye5LcE/QB5sPATrN77AnNzUO2/XEYS64UwCiW7xRXhQl Xw0jBvfTGj+1eHdPIakjn8FzpwUXgUogqgxGb32Z+Zbkg+JCw74jtqF8dnBDdoOKnS1e 71j+ZSR+BWV7kgMn0Rq9Mxz2Woa9JvJuIAMCgoBovOjeyaodUTyhk6o2uV6irdMBoaC5 7LKDYR7gK7VEUgMcp062p5DNNsnp4JBkND4u1Xu7hzg84WoN1G/ooLmgPR0CG5RcYsGB pI3c/g2BvTRgCM05T6PH7e/dkXA2x7dksaNviQN1gQoKKbO0Og2aONKiYQc2FopXQTrZ Sx9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Uu2v08cw; spf=pass (google.com: domain of srs0=nia/=ii=linuxfoundation.org=gregkh@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=SRS0=nia/=II=linuxfoundation.org=gregkh@kernel.org Received: from mail.kernel.org (mail.kernel.org. [198.145.29.99]) by mx.google.com with ESMTPS id p33-v6si13444007pld.318.2018.05.20.23.42.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 May 2018 23:42:27 -0700 (PDT) Received-SPF: pass (google.com: domain of srs0=nia/=ii=linuxfoundation.org=gregkh@kernel.org designates 198.145.29.99 as permitted sender) client-ip=198.145.29.99; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Uu2v08cw; spf=pass (google.com: domain of srs0=nia/=ii=linuxfoundation.org=gregkh@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=SRS0=nia/=II=linuxfoundation.org=gregkh@kernel.org Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D99C020871; Mon, 21 May 2018 06:42:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1526884947; bh=lOBfNaQNfYH3em5GbMSRRwP6aT6tv3F4AtzETu0MS8U=; h=Subject:To:Cc:From:Date:From; b=Uu2v08cwrXTsq1mvwYazoYWGJRxOBGHIm9XA+/xqiWHlCsE/MbBB+GIrR19xR7+mA NDd76EsqfEpqUplItYRsiP2lOKsEWKtLsERBljL+fmio6PrzykFVwwhIYTFylwgVwv oFrL+sHzwAIL8jGbbwMHcKhykdrNBnJsII9+QzGQ= Subject: Patch "x86/pkeys: Override pkey when moving away from PROT_EXEC" has been added to the 4.14-stable tree To: 20180509171351.084C5A71@viggo.jf.intel.com, akpm@linux-foundation.org, dave.hansen@intel.com, dave.hansen@linux.intel.com, gregkh@linuxfoundation.org, linux-mm@kvack.org, linuxram@us.ibm.com, mingo@kernel.org, mpe@ellerman.id.au, peterz@infradead.org, shakeelb@google.com, shuah@kernel.org, tglx@linutronix.de, torvalds@linux-foundation.org Cc: From: Date: Mon, 21 May 2018 08:41:29 +0200 Message-ID: <152688488911097@kroah.com> MIME-Version: 1.0 X-stable: commit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP This is a note to let you know that I've just added the patch titled x86/pkeys: Override pkey when moving away from PROT_EXEC to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: x86-pkeys-override-pkey-when-moving-away-from-prot_exec.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. From 0a0b152083cfc44ec1bb599b57b7aab41327f998 Mon Sep 17 00:00:00 2001 From: Dave Hansen Date: Wed, 9 May 2018 10:13:51 -0700 Subject: x86/pkeys: Override pkey when moving away from PROT_EXEC From: Dave Hansen commit 0a0b152083cfc44ec1bb599b57b7aab41327f998 upstream. 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. Reported-by: Shakeel Butt Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Dave Hansen Cc: Linus Torvalds Cc: Michael Ellermen Cc: Peter Zijlstra Cc: Ram Pai Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-mm@kvack.org Cc: stable@vger.kernel.org Fixes: 62b5f7d013f ("mm/core, x86/mm/pkeys: Add execute-only protection keys support") Link: http://lkml.kernel.org/r/20180509171351.084C5A71@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/asm/pkeys.h | 12 +++++++++++- arch/x86/mm/pkeys.c | 21 +++++++++++---------- 2 files changed, 22 insertions(+), 11 deletions(-) Patches currently in stable-queue which might be from dave.hansen@linux.intel.com are queue-4.14/x86-pkeys-override-pkey-when-moving-away-from-prot_exec.patch queue-4.14/x86-pkeys-do-not-special-case-protection-key-0.patch --- a/arch/x86/include/asm/pkeys.h +++ b/arch/x86/include/asm/pkeys.h @@ -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); } --- a/arch/x86/mm/pkeys.c +++ b/arch/x86/mm/pkeys.c @@ -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