From patchwork Tue Mar 27 01:16:30 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ram Pai X-Patchwork-Id: 891298 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 409Cp32P8vz9s0b for ; Tue, 27 Mar 2018 12:18:51 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=us.ibm.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="LqoMktvg"; dkim-atps=neutral Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 409Cp30mvvzF27c for ; Tue, 27 Mar 2018 12:18:51 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=us.ibm.com Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="LqoMktvg"; dkim-atps=neutral X-Original-To: linuxppc-dev@lists.ozlabs.org Delivered-To: linuxppc-dev@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:400d:c0d::243; helo=mail-qt0-x243.google.com; envelope-from=ram.n.pai@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=us.ibm.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="LqoMktvg"; dkim-atps=neutral Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 409Cld3F8kzF27X for ; Tue, 27 Mar 2018 12:16:44 +1100 (AEDT) Received: by mail-qt0-x243.google.com with SMTP id w12so14050848qti.4 for ; Mon, 26 Mar 2018 18:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id; bh=8zT3PYzTMN7OaC51LXCgbfvPr7O6eoFxSgj4Fu/BLLc=; b=LqoMktvg3G6+ODvpdJVSaU+a9QtxD+4bHlbFdTwzpGvnLVAeSLb2SfITtM8zIYtemf JhvzMZCyz7VXo+zZCbUjzwpzsrSURqNecle06yTBVv9f8cHHnBAnpc0/micIFTTz31jD +Cyn/Y/49bR3kipvyZ1+FoYrbWCq6U65w2Lge5dzY7jZv9FDBL6s/UMLA+msZH/dUN1P jG9rv0rM8jaEQ8WLP0vDotJBRUxDMwvOoutZDnbWHF7UduXr4Z9U8B4cFqp2Gr9eHOSu ytS2dMOgscEyz1dgotE0VKUlAsr8hy7rHVUDyxPS423nFmeUdtH/9S2AI1Os7NUE6GBz 2BQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id; bh=8zT3PYzTMN7OaC51LXCgbfvPr7O6eoFxSgj4Fu/BLLc=; b=H2yke4+fq+hEyO4Y80HSYrGHg0bSjVovaGquALVFE7qnoSezq0LGsQhyW27EhQPLe+ 5e6cpTqtPejVEZWSIKcaxLRk3tlLTFBFoX56hP4OP9meq01mEMo9tm3V9mysRXtBxBo/ ztkrMShymo75rdWIhnuisp9bDePcIHmjDsBAChXcx8ZOPOejWOHv8JDp6f+dufgLp+1v G9SxTxTNtQUhwKM8FDaM+Edz5b/FGI1ccetC+pErbYkH3WcmvvY3sQhpq1nZUkuoctbA Ok5QVcohq41di9RT8SbynLJ729W8FMx18HWKVffw3uPK8uPzpfsJ3oLiUqqD6McaRdtY tZtw== X-Gm-Message-State: AElRT7Gs/2RmEzATvRVZPkSWs07WEBHcSbNW160VAabGacB3MmDA1BIw nzUvgZQLZ3Kumx470G7BLsyYKg== X-Google-Smtp-Source: AG47ELv544xmkYbGFS6hlokguAjEY7pbskWzAn5rL14iOcEy+T07No4CCdF4YgPmHX+INqGEci831Q== X-Received: by 10.200.54.109 with SMTP id n42mr57274811qtb.271.1522113402429; Mon, 26 Mar 2018 18:16:42 -0700 (PDT) Received: from localhost.localdomain (50-39-100-161.bvtn.or.frontiernet.net. [50.39.100.161]) by smtp.gmail.com with ESMTPSA id e64sm61101qka.18.2018.03.26.18.16.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 18:16:41 -0700 (PDT) From: Ram Pai To: mpe@ellerman.id.au Subject: [PATCH] powerpc: do not allow userspace to modify execute-only pkey Date: Mon, 26 Mar 2018 18:16:30 -0700 Message-Id: <1522113390-29240-1-git-send-email-linuxram@us.ibm.com> X-Mailer: git-send-email 1.7.1 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: fweimer@redhat.com, msuchanek@suse.com, linuxram@us.ibm.com, mhocko@kernel.org, paulus@samba.org, aneesh.kumar@linux.vnet.ibm.com, bauerman@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" When mprotect(....,PROT_EXEC) is called, the kernel allocates a execute-only pkey and associates the pkey with the given address space. The permission of this key should not be modifiable from userspace. However a bug in the current implementation lets the permissions on the key modifiable from userspace. Whenever a key is allocated through mm_pkey_alloc(), the kernel programs the UAMOR register to allow userspace to change permissions on the key. This is fine for the keys explicitly allocated through the sys_pkey_alloc(). But for execute-only pkey, this should not be allowed. Restructured the code to fix the bug. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/pkeys.h | 24 ++++++------------------ arch/powerpc/mm/pkeys.c | 30 ++++++++++++++++++++++++++++-- 2 files changed, 34 insertions(+), 20 deletions(-) diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h index b598fa9..0d3c630 100644 --- a/arch/powerpc/include/asm/pkeys.h +++ b/arch/powerpc/include/asm/pkeys.h @@ -113,6 +113,8 @@ static inline bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey) extern void __arch_activate_pkey(int pkey); extern void __arch_deactivate_pkey(int pkey); +extern int __mm_pkey_alloc(struct mm_struct *mm); + /* * Returns a positive, 5-bit key on success, or -1 on failure. * Relies on the mmap_sem to protect against concurrency in mm_pkey_alloc() and @@ -120,29 +122,14 @@ static inline bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey) */ static inline int mm_pkey_alloc(struct mm_struct *mm) { - /* - * Note: this is the one and only place we make sure that the pkey is - * valid as far as the hardware is concerned. The rest of the kernel - * trusts that only good, valid pkeys come out of here. - */ - u32 all_pkeys_mask = (u32)(~(0x0)); int ret; if (static_branch_likely(&pkey_disabled)) return -1; + ret = __mm_pkey_alloc(mm); /* - * Are we out of pkeys? We must handle this specially because ffz() - * behavior is undefined if there are no zeros. - */ - if (mm_pkey_allocation_map(mm) == all_pkeys_mask) - return -1; - - ret = ffz((u32)mm_pkey_allocation_map(mm)); - __mm_pkey_allocated(mm, ret); - - /* - * Enable the key in the hardware + * Enable userspace to modify the key permissions. */ if (ret > 0) __arch_activate_pkey(ret); @@ -158,7 +145,8 @@ static inline int mm_pkey_free(struct mm_struct *mm, int pkey) return -EINVAL; /* - * Disable the key in the hardware + * Reset the key and disable userspace + * from modifying the key permissions. */ __arch_deactivate_pkey(pkey); __mm_pkey_free(mm, pkey); diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c index e7a9e34..58bbb55 100644 --- a/arch/powerpc/mm/pkeys.c +++ b/arch/powerpc/mm/pkeys.c @@ -228,7 +228,10 @@ static void pkey_status_change(int pkey, bool enable) init_amr(pkey, 0x0); init_iamr(pkey, 0x0); - /* Enable/disable key */ + /* + * Enable/disable userspace to/from modifying the permissions + * on the key + */ old_uamor = read_uamor(); if (enable) old_uamor |= (0x3ul << pkeyshift(pkey)); @@ -247,6 +250,29 @@ void __arch_deactivate_pkey(int pkey) pkey_status_change(pkey, false); } +int __mm_pkey_alloc(struct mm_struct *mm) +{ + /* + * Note: this is the one and only place we make sure that the pkey is + * valid as far as the hardware is concerned. The rest of the kernel + * trusts that only good, valid pkeys come out of here. + */ + u32 all_pkeys_mask = (u32)(~(0x0)); + int ret; + + /* + * Are we out of pkeys? We must handle this specially because ffz() + * behavior is undefined if there are no zeros. + */ + if (mm_pkey_allocation_map(mm) == all_pkeys_mask) + return -1; + + ret = ffz((u32)mm_pkey_allocation_map(mm)); + __mm_pkey_allocated(mm, ret); + + return ret; +} + /* * Set the access rights in AMR IAMR and UAMOR registers for @pkey to that * specified in @init_val. @@ -336,7 +362,7 @@ int __execute_only_pkey(struct mm_struct *mm) /* Do we need to assign a pkey for mm's execute-only maps? */ if (execute_only_pkey == -1) { /* Go allocate one to use, which might fail */ - execute_only_pkey = mm_pkey_alloc(mm); + execute_only_pkey = __mm_pkey_alloc(mm); if (execute_only_pkey < 0) return -1; need_to_set_mm_pkey = true;