From patchwork Fri May 4 19:22:58 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ram Pai X-Patchwork-Id: 909012 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 40d2CR32vSz9s2k for ; Sat, 5 May 2018 05:29:55 +1000 (AEST) 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="S7T8mIi/"; dkim-atps=neutral Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 40d2CR0z4lzDrj5 for ; Sat, 5 May 2018 05:29:55 +1000 (AEST) 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="S7T8mIi/"; 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:c09::244; helo=mail-qk0-x244.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="S7T8mIi/"; dkim-atps=neutral Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 40d2493MKzzDrLj for ; Sat, 5 May 2018 05:23:34 +1000 (AEST) Received: by mail-qk0-x244.google.com with SMTP id a202so17501742qkg.3 for ; Fri, 04 May 2018 12:23:34 -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=IN2jnxd7x5b1ItO1OoG/s6Hlt239i4aIQ4g0cAGa7LU=; b=S7T8mIi/62zI1dDxoKNstLIdQLwH3u6nHClJSA/LJSULIR+Y89T04r1XUh5OJ4WijL vVmnB/D1IMPJlefkuyIr0tYuar1cwwFNUHwjj5tsu2eDI2cnhIQptSntAm3o8iZgxGhT L1pJZabusgAId0q3bIbummcAcyZ338+YXI/ZbMd1/Fh/L7q834YeX1wI71saZzs3kU+g 0A8sZrpYqCyQsflSQvb8+2vxm4vO2JYIBPxclVZifEZFXgrt5YF3Hc+zGa+nA3bM3998 xRIa0kL1wwpracTxDgayavXbSk3lCraQ4DJ2ala83Vk2y/VyLCakBqOaGw5nuGpAN8np GBZw== 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=IN2jnxd7x5b1ItO1OoG/s6Hlt239i4aIQ4g0cAGa7LU=; b=iPEDQ2Bwzz8dbtCEV0upXT8RjGbr8ryHAJQmtYrOE1QcjtAsJAOzuubAtUow0JRng2 SORONkd7HnRVgJwpB0RsaW6G2+iJGjop2jGLeU0/TcHxIMUrAT8kVdYbdKlC6kz18pB2 IY6KrMIGTzu0sYEXKagN4n04zPlqELWD+cMuWSMEOc6hDFLPpHCRFpWU1kv7l50/uZtQ kVVHbviYBD7STBoeVSsL0/9xPJg3QUF/x8f1m79Wkk9xE07DIWcMx8g+ugIDNyTjHxOb yJf2cAMoPCNxfdpwserqk4qlnhT+1UHD/LUz8wtqCNUl3r8tebA//XuZ4lhoHZMTK4qj 8AGA== X-Gm-Message-State: ALQs6tAcpcad6S5FV8b/K9irc0eKuM6JUwtI4UvoUW/0znEN70T38ABk 2lXtt1ocEgiicfWXF6FDW6E= X-Google-Smtp-Source: AB8JxZo8cNO98CrBc615iDDEFx/ZUFqFEySP65Fw6LG/fvJ5lvr6h7A8Uo8jiOUFtvFs3H2iZQce0g== X-Received: by 10.55.184.132 with SMTP id i126mr21519943qkf.191.1525461811670; Fri, 04 May 2018 12:23:31 -0700 (PDT) Received: from localhost.localdomain ([170.225.9.142]) by smtp.gmail.com with ESMTPSA id c24-v6sm7144266qtp.22.2018.05.04.12.23.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 May 2018 12:23:31 -0700 (PDT) From: Ram Pai To: mpe@ellerman.id.au Subject: [PATCH v3] powerpc, pkey: make protection key 0 less special Date: Fri, 4 May 2018 12:22:58 -0700 Message-Id: <1525461778-26265-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, Andrew Morton , Ulrich.Weigand@de.ibm.com, Ingo Molnar , linuxram@us.ibm.com, mhocko@kernel.org, paulus@samba.org, aneesh.kumar@linux.vnet.ibm.com, bauerman@linux.vnet.ibm.com, Thomas Gleixner , linuxppc-dev@lists.ozlabs.org, Dave Hansen Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" Applications need the ability to associate an address-range with some key and latter revert to its initial default key. Pkey-0 comes close to providing this function but falls short, because the current implementation disallows applications to explicitly associate pkey-0 to the address range. Lets make pkey-0 less special and treat it almost like any other key. Thus it can be explicitly associated with any address range, and can be freed. This gives the application more flexibility and power. The ability to free pkey-0 must be used responsibily, since pkey-0 is associated with almost all address-range by default. Even with this change pkey-0 continues to be slightly more special from the following point of view. (a) it is implicitly allocated. (b) it is the default key assigned to any address-range. (c) its permissions cannot be modified by userspace. NOTE: (c) is specific to powerpc only. pkey-0 is associated by default with all pages including kernel pages, and pkeys are also active in kernel mode. If any permission is denied on pkey-0, the kernel running in the context of the application will be unable to operate. Tested on powerpc. cc: Thomas Gleixner cc: Dave Hansen cc: Michael Ellermen cc: Ingo Molnar cc: Andrew Morton Signed-off-by: Ram Pai --- History: v3: . Corrected a comment in arch_set_user_pkey_access(). . Clarified the header, to capture the notion that pkey-0 permissions cannot be modified by userspace on powerpc. -- comment from Thiago v2: . mm_pkey_is_allocated() continued to treat pkey-0 special. fixed it. arch/powerpc/include/asm/pkeys.h | 22 ++++++++++++++++++---- arch/powerpc/mm/pkeys.c | 26 +++++++++++++++----------- 2 files changed, 33 insertions(+), 15 deletions(-) diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h index 0409c80..31a6976 100644 --- a/arch/powerpc/include/asm/pkeys.h +++ b/arch/powerpc/include/asm/pkeys.h @@ -101,10 +101,14 @@ static inline u16 pte_to_pkey_bits(u64 pteflags) static inline bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey) { - /* A reserved key is never considered as 'explicitly allocated' */ - return ((pkey < arch_max_pkey()) && - !__mm_pkey_is_reserved(pkey) && - __mm_pkey_is_allocated(mm, pkey)); + if (pkey < 0 || pkey >= arch_max_pkey()) + return false; + + /* Reserved keys are never allocated. */ + if (__mm_pkey_is_reserved(pkey)) + return false; + + return __mm_pkey_is_allocated(mm, pkey); } extern void __arch_activate_pkey(int pkey); @@ -200,6 +204,16 @@ static inline int arch_set_user_pkey_access(struct task_struct *tsk, int pkey, { if (static_branch_likely(&pkey_disabled)) return -EINVAL; + + /* + * userspace should not change pkey-0 permissions. + * pkey-0 is associated with every page in the kernel. + * If userspace denies any permission on pkey-0, the + * kernel cannot operate. + */ + if (!pkey) + return init_val ? -EINVAL : 0; + return __arch_set_user_pkey_access(tsk, pkey, init_val); } diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c index 0eafdf0..d6873b4 100644 --- a/arch/powerpc/mm/pkeys.c +++ b/arch/powerpc/mm/pkeys.c @@ -119,16 +119,21 @@ int pkey_initialize(void) #else os_reserved = 0; #endif + /* Bits are in LE format. */ initial_allocation_mask = ~0x0; + + /* register mask is in BE format */ pkey_amr_uamor_mask = ~0x0ul; pkey_iamr_mask = ~0x0ul; - /* - * key 0, 1 are reserved. - * key 0 is the default key, which allows read/write/execute. - * key 1 is recommended not to be used. PowerISA(3.0) page 1015, - * programming note. - */ - for (i = 2; i < (pkeys_total - os_reserved); i++) { + + for (i = 0; i < (pkeys_total - os_reserved); i++) { + /* + * key 1 is recommended not to be used. + * PowerISA(3.0) page 1015, + */ + if (i == 1) + continue; + initial_allocation_mask &= ~(0x1 << i); pkey_amr_uamor_mask &= ~(0x3ul << pkeyshift(i)); pkey_iamr_mask &= ~(0x1ul << pkeyshift(i)); @@ -142,7 +147,9 @@ void pkey_mm_init(struct mm_struct *mm) { if (static_branch_likely(&pkey_disabled)) return; - mm_pkey_allocation_map(mm) = initial_allocation_mask; + + /* allocate key-0 by default */ + mm_pkey_allocation_map(mm) = initial_allocation_mask | 0x1; /* -1 means unallocated or invalid */ mm->context.execute_only_pkey = -1; } @@ -407,9 +414,6 @@ static bool pkey_access_permitted(int pkey, bool write, bool execute) int pkey_shift; u64 amr; - if (!pkey) - return true; - if (!is_pkey_enabled(pkey)) return true;