linux-kernel - [PATCH] powerpc, pkey: make protection key 0 less special

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 26 Mar 2018 16:31:41 -0700
From:   Ram Pai <linuxram@...ibm.com>
To:     mpe@...erman.id.au, mingo@...hat.com, akpm@...ux-foundation.org
Cc:     linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        dave.hansen@...el.com, benh@...nel.crashing.org, paulus@...ba.org,
        aneesh.kumar@...ux.vnet.ibm.com, bsingharora@...il.com,
        hbabu@...ibm.com, mhocko@...nel.org, bauerman@...ux.vnet.ibm.com,
        linuxram@...ibm.com, fweimer@...hat.com, msuchanek@...e.com,
        tglx@...utronix.de, shuah@...nel.org
Subject: [PATCH] powerpc, pkey: make protection key 0 less special

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.

Tested on powerpc.

cc: Thomas Gleixner <tglx@...utronix.de>
cc: Dave Hansen <dave.hansen@...el.com>
cc: Michael Ellermen <mpe@...erman.id.au>
cc: Ingo Molnar <mingo@...nel.org>
cc: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: Ram Pai <linuxram@...ibm.com>
---
 arch/powerpc/include/asm/pkeys.h | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
index 0409c80..9c7d3bd 100644
--- a/arch/powerpc/include/asm/pkeys.h
+++ b/arch/powerpc/include/asm/pkeys.h
@@ -101,10 +101,18 @@ 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));
+	/* pkey 0 is allocated by default. */
+	if (!pkey)
+		return true;
+
+	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 +208,14 @@ static inline int arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
 {
 	if (static_branch_likely(&pkey_disabled))
 		return -EINVAL;
+
+	/*
+	 * userspace is discouraged from changing permissions of
+	 * pkey-0. powerpc hardware does not support it anyway.
+	 */
+	if (!pkey)
+		return init_val ? -EINVAL : 0;
+
 	return __arch_set_user_pkey_access(tsk, pkey, init_val);
 }
 
-- 
1.8.3.1