From patchwork Wed May 9 17:13:51 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Hansen X-Patchwork-Id: 10390255 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 A6A1A60318 for ; Wed, 9 May 2018 17:19:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 958682851A for ; Wed, 9 May 2018 17:19:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8A2552851E; Wed, 9 May 2018 17:19:15 +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, 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 F24172851A for ; Wed, 9 May 2018 17:19:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A35E6B0545; Wed, 9 May 2018 13:18:59 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 654156B0546; Wed, 9 May 2018 13:18:59 -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 4824E6B0547; Wed, 9 May 2018 13:18:59 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pf0-f200.google.com (mail-pf0-f200.google.com [209.85.192.200]) by kanga.kvack.org (Postfix) with ESMTP id ED1156B0545 for ; Wed, 9 May 2018 13:18:58 -0400 (EDT) Received: by mail-pf0-f200.google.com with SMTP id z1so10718050pfh.3 for ; Wed, 09 May 2018 10:18:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:subject:to:cc :from:date:references:in-reply-to:message-id; bh=/XiA5eadDpm+1c83WTmG0fote4PdZrEd1hQ35DrJ/DY=; b=U7FV5SkwCfHoZwU1kpZRBugKpnxe++sKSX0mASUqK+NZ9jndMD9EBCqtDor8p5gpo4 SsZ+J7kwsDVhNhW+Pv/DCIDr6yDYz4ezLeJQeL4OjBQy6TwHRBpcQH9jox9j9kvx5/Gk +o0wrt1xLuW/9KSmoAXUdXziyisHjMrhf0esORmiV/foO2hlbd2Ngjo3NvPqLgsVQlP8 0/yXwcA+BQefTZloqerthv163M8B19Tym16qaZjslVQm252kMYGcj+12ZS42jRZIrXzY Eyz0ItSFInwuoPxpeX4NbEhVN+YHmbEGLjQiiF1wSKiUxILqk9e8qa9OET3QIkdYLQAI h/7w== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of dave.hansen@linux.intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=dave.hansen@linux.intel.com X-Gm-Message-State: ALKqPwcg08Yqms2e/3GaqbzTpdlxG9wHGjv0mvoMEb3cT9DxNt3QCju1 QpADYCsKsiDFNTkhisLDf9quhNd8OgCvKX1h5SdKzCBknHRT1L3O4hdFlbhK0u8u7/n/W4TMnBR uVLVG1qHvh7D+2+4ECyw49OXwM9M5eiprMZcj0W1WdQsOCJhLrRcmtsgXb7USeg41nw== X-Received: by 2002:a63:924c:: with SMTP id s12-v6mr3495180pgn.368.1525886338615; Wed, 09 May 2018 10:18:58 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoVqPNIHODEt7WYHRL3tUWKOG0kK8hXk5yYDA1sjwjCb8rN9BORAelfBR04Tc+M9/FoWh4d X-Received: by 2002:a63:924c:: with SMTP id s12-v6mr3495153pgn.368.1525886337816; Wed, 09 May 2018 10:18:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525886337; cv=none; d=google.com; s=arc-20160816; b=jyYD0I0k7lNN7dz3Qzzki+6sZfWKVHZVfJzRiv5ZNrLS5F8fd8tOgH8TxJFqud+kmd 5sKf0/qyTTbAuYqEFZBZHP32xi27PwTFGzzOZqHflPK6kD79DO6Rd5NFkHNxWNU6Ho05 j46nHqIIGV163hJoJRfKB6MDfFz9qwiq8pLx0CqVlbWzmGRl5+TpEbun1UxRSKq5BYII WaZeNK/T4EOAYke3WfWaqyL6etHrEja/GkTIcF505CKJNvf+i4MwJVRbYiTPMh7TjlEm OlE+cvAM9GASWDcqtwK97gGo50efs6b2Th9LT2xQMY7X0wPf8/fbFTnreM/SLrCWU2J4 sL9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:in-reply-to:references:date:from:cc:to:subject :arc-authentication-results; bh=/XiA5eadDpm+1c83WTmG0fote4PdZrEd1hQ35DrJ/DY=; b=aehy9M8cFU715GctIYkWpw93zd3c/4fD4IB4IjV27kiOdT84/09H+o3VeKKOpctutM GXTEkT+PcFF0XnsSL0Jfvl+vgmy5iFLuXhSj9fOj5U0okczBmv0qVKU6c/l04D6D09jI 845VSd7sPASeA9d1RFv1kFeFMI9aC/2Pap+0fMUJKFhTRgWTRN9N5gzG/3n2f/DHk2Yj 1o02m/P9vkKjNrS3X+25F/cOTCCUZC24v6kqII0hkYIWYR4IZlBIH25g3ZwVDuh7oAJI mAcKp8mnOCB/XXJzJrPjlvriLGy0JMc0as0ckFgH+sGTbvk3u1877Yt/vDZX2k9v+D0L Lw0Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of dave.hansen@linux.intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=dave.hansen@linux.intel.com Received: from mga04.intel.com (mga04.intel.com. [192.55.52.120]) by mx.google.com with ESMTPS id s196-v6si3202216pgc.567.2018.05.09.10.18.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 May 2018 10:18:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of dave.hansen@linux.intel.com designates 192.55.52.120 as permitted sender) client-ip=192.55.52.120; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of dave.hansen@linux.intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=dave.hansen@linux.intel.com X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2018 10:18:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,382,1520924400"; d="scan'208";a="39684411" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.39.119]) by orsmga007.jf.intel.com with ESMTP; 09 May 2018 10:18:56 -0700 Subject: [PATCH 09/13] x86/pkeys: Override pkey when moving away from PROT_EXEC To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, Dave Hansen , 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 From: Dave Hansen Date: Wed, 09 May 2018 10:13:51 -0700 References: <20180509171336.76636D88@viggo.jf.intel.com> In-Reply-To: <20180509171336.76636D88@viggo.jf.intel.com> Message-Id: <20180509171351.084C5A71@viggo.jf.intel.com> 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 From: Dave Hansen 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 Fixes: 62b5f7d013f ("mm/core, x86/mm/pkeys: Add execute-only protection keys support") Reported-by: Shakeel Butt Cc: stable@vger.kernel.org Cc: Ram Pai Cc: Thomas Gleixner Cc: Dave Hansen Cc: Michael Ellermen Cc: Ingo Molnar Cc: Andrew Morton Cc: Shuah Khan --- 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-05-09 09:20:22.295698398 -0700 +++ b/arch/x86/include/asm/pkeys.h 2018-05-09 09:20:22.300698398 -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-05-09 09:20:22.297698398 -0700 +++ b/arch/x86/mm/pkeys.c 2018-05-09 09:20:22.301698398 -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