From patchwork Mon May 21 21:11:43 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 10416587 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 D3555600CC for ; Mon, 21 May 2018 21:24:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C276628A77 for ; Mon, 21 May 2018 21:24:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B713F28A7C; Mon, 21 May 2018 21:24:05 +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 0BE1728A77 for ; Mon, 21 May 2018 21:24:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A10C16B0006; Mon, 21 May 2018 17:24:03 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 9C0846B0008; Mon, 21 May 2018 17:24:03 -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 8D5896B000A; Mon, 21 May 2018 17:24:03 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pl0-f70.google.com (mail-pl0-f70.google.com [209.85.160.70]) by kanga.kvack.org (Postfix) with ESMTP id 4EBE66B0006 for ; Mon, 21 May 2018 17:24:03 -0400 (EDT) Received: by mail-pl0-f70.google.com with SMTP id a5-v6so10666098plp.8 for ; Mon, 21 May 2018 14:24:03 -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:from:to:cc:subject:date :message-id:in-reply-to:references:user-agent:mime-version; bh=sZW8kXYr4BVq+DsKhS6cba1fOTlwV7rBGM1BWXAEZpA=; b=gp2+TuBUuJ6hMwqv31Hyj4a2bdeYy2jiLD+DzG9e/4uNFFWAmX4vntVdyIuG0a464u fbhGy4Na8FKE9maVCv751P2e9e5Ul/0uVUUvGdDffsjm6Frj6OzQpRJ9pFexlXqC67gA zxiufcnDRTgE8LMQxq36Sg34bPLvGz2anUtHBeRBaL8abD/kNgczQLDNA3rsPYRGZ2UC Yx5tHtEIA7L5I49hF3yFZf02EdyKe5vlgR3jjr8pBQYGKlUie4qN8ZRxZFdwPrjZpuLf 8IISI+6RClqCL7OpEbCgx3502oLdjvfactM6pOWQ6Dk4KLqp6ahfnUOWr/YAbUfaQNxq 02Cg== X-Gm-Message-State: ALKqPwe/+I7+Zii9Xa+7/2IsQZtTXqZBbtyzlyqvXvbfwKmon2j6geC+ 02z98HBSSaedoLI7O4Jf22xH51wQ8CAQj6cAtZjqfVa0+yBTexSbK3QySJ2p2UK2S8hJEjUJXaL jHg7oSUlYwF097rJ5Z4tRHRcG54+mQlzLRdCGO6gT6uUXgl4ZN2V5MFMeGfATwqQ= X-Received: by 2002:a17:902:d707:: with SMTP id w7-v6mr17541588ply.142.1526937843004; Mon, 21 May 2018 14:24:03 -0700 (PDT) X-Google-Smtp-Source: AB8JxZobH4CFaOIyhvHNp2aHoDMdxovWF8B3/NfKRWh61RDc+C/peOB5112IKHyf7Ktf1cQw4tKC X-Received: by 2002:a17:902:d707:: with SMTP id w7-v6mr17541558ply.142.1526937842300; Mon, 21 May 2018 14:24:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526937842; cv=none; d=google.com; s=arc-20160816; b=ypWmYWTlowBQavt8VjduZwzRb6m/3M8tNBnZRZplNy3vdy3B3GXfwbWT+Sz64f259Q cdp3isF8BynUgjkkDI7qd+NWUeQBCQhTMR/3JaMus6Zuf+cPTPGFE3I571lT6enI7rPN devIQ8qyS1pAJjwhofWpsGCsSgsh/YC46NuvBtNC7wHx6uu61zbBe0/oCn+s7gTyOfyS 5rkr0B03eXfDRMRAzRjD8HuM3SCleCT2ldgFQj2D3h2qpJ3EHmN1buf71D1TLmRxmB79 GU0J0rSO4XXc67p66OhnPEg2uoS0raqZ1RLox5D1O/LNHZKTSEaJjYCFbZJDj8g3fLsP MXoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=sZW8kXYr4BVq+DsKhS6cba1fOTlwV7rBGM1BWXAEZpA=; b=Ko8Qz8krFcPYmXnCDydBkwyK8RwnDYYXCsqHz2qoiw1aOlI0x3iJ3qbulHFhlVo86F 2B3Wf4B3NC8mmRiTdkWQrGzAhANm6azJo0+gNw9kNaqCybsWX8hQE5uGSO9pufeSBzse lUJC4iHyqvWyxmVSPvrOLK+OmxZ5wD+FUFV5qP4OO8RPH8B1hchXn6QX0qr3gQ7DGf3i EMUFgaI450+LtMsPWEIBiZOXVQ36g+x+LRSrlItjE0uNiu4afiDLJ4j6iOh9SE1P4m/0 SBKB/OAjmoC+z1Chjq2e2DIkM5Rl3Fu7FcqwyZHywGLBpgbBoXGpxPF8qJ8W6Pr+0nMn KQOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=waLjnWb7; 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 f127-v6si9035992pgc.503.2018.05.21.14.24.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 May 2018 14:24:02 -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=waLjnWb7; 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 7117320871; Mon, 21 May 2018 21:24:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1526937842; bh=3FHdsPk4ureDKhg9TmBDCM2FzsaDUtBcIpO/N2Jyz4E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=waLjnWb7spr2ayPMczJrDcSgn7mhRPD7n7m2tgezSor5dzNgrS83r6s7wN1btsaan uTrBwbddc6k7I1PNmDdj50J0dPGpFC8IMvAjgFFSUANtUq1ZG1wgbmf3llGJ3BKjeN VpEieks9RtZ3R8RMS9wWABFjCd1bGtyxBozUYCOY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dave Hansen , Dave Hansen , Linus Torvalds , Michael Ellermen , Peter Zijlstra , Ram Pai , Shuah Khan , Thomas Gleixner , linux-mm@kvack.org, Ingo Molnar , Andrew Morton Subject: [PATCH 4.16 046/110] x86/pkeys: Do not special case protection key 0 Date: Mon, 21 May 2018 23:11:43 +0200 Message-Id: <20180521210508.373502928@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180521210503.823249477@linuxfoundation.org> References: <20180521210503.823249477@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 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 4.16-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dave Hansen commit 2fa9d1cfaf0e02f8abef0757002bff12dfcfa4e6 upstream. mm_pkey_is_allocated() treats pkey 0 as unallocated. That is inconsistent with the manpages, and also inconsistent with mm->context.pkey_allocation_map. Stop special casing it and only disallow values that are actually bad (< 0). The end-user visible effect of this is that you can now use mprotect_pkey() to set pkey=0. This is a bit nicer than what Ram proposed[1] because it is simpler and removes special-casing for pkey 0. On the other hand, it does allow applications to pkey_free() pkey-0, but that's just a silly thing to do, so we are not going to protect against it. The scenario that could happen is similar to what happens if you free any other pkey that is in use: it might get reallocated later and used to protect some other data. The most likely scenario is that pkey-0 comes back from pkey_alloc(), an access-disable or write-disable bit is set in PKRU for it, and the next stack access will SIGSEGV. It's not horribly different from if you mprotect()'d your stack or heap to be unreadable or unwritable, which is generally very foolish, but also not explicitly prevented by the kernel. 1. http://lkml.kernel.org/r/1522112702-27853-1-git-send-email-linuxram@us.ibm.com Signed-off-by: Dave Hansen Cc: Andrew Morton p 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: 58ab9a088dda ("x86/pkeys: Check against max pkey to avoid overflows") Link: http://lkml.kernel.org/r/20180509171358.47FD785E@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/asm/mmu_context.h | 2 +- arch/x86/include/asm/pkeys.h | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) --- a/arch/x86/include/asm/mmu_context.h +++ b/arch/x86/include/asm/mmu_context.h @@ -192,7 +192,7 @@ static inline int init_new_context(struc #ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS if (cpu_feature_enabled(X86_FEATURE_OSPKE)) { - /* pkey 0 is the default and always allocated */ + /* pkey 0 is the default and allocated implicitly */ mm->context.pkey_allocation_map = 0x1; /* -1 means unallocated or invalid */ mm->context.execute_only_pkey = -1; --- a/arch/x86/include/asm/pkeys.h +++ b/arch/x86/include/asm/pkeys.h @@ -51,10 +51,10 @@ bool mm_pkey_is_allocated(struct mm_stru { /* * "Allocated" pkeys are those that have been returned - * from pkey_alloc(). pkey 0 is special, and never - * returned from pkey_alloc(). + * from pkey_alloc() or pkey 0 which is allocated + * implicitly when the mm is created. */ - if (pkey <= 0) + if (pkey < 0) return false; if (pkey >= arch_max_pkey()) return false;