[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201203190426.5a2cc067@canb.auug.org.au>
Date: Thu, 3 Dec 2020 19:06:01 +1100
From: Stephen Rothwell <sfr@...b.auug.org.au>
To: Andrew Morton <akpm@...ux-foundation.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>
Cc: Andrey Konovalov <andreyknvl@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Mark Rutland <mark.rutland@....com>,
Vincenzo Frascino <vincenzo.frascino@....com>
Subject: linux-next: manual merge of the akpm-current tree with the arm64
tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/arm64/include/asm/uaccess.h
between commits:
923e1e7d8223 ("arm64: uaccess: rename privileged uaccess routines")
7cf283c7bd62 ("arm64: uaccess: remove redundant PAN toggling")
from the arm64 tree and commit:
9bc0016cc21a ("arm64: mte: add in-kernel tag fault handler")
from the akpm-current tree.
I fixed it up (as specified by Catalin (thanks) see below) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/include/asm/uaccess.h
index d841a560fae7,abb31aa1f8ca..000000000000
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@@ -186,64 -159,20 +159,43 @@@ static inline void __uaccess_enable_hw_
CONFIG_ARM64_PAN));
}
- #define __uaccess_disable(alt) \
- do { \
- if (!uaccess_ttbr0_disable()) \
- asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), alt, \
- CONFIG_ARM64_PAN)); \
- } while (0)
-
- #define __uaccess_enable(alt) \
- do { \
- if (!uaccess_ttbr0_enable()) \
- asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt, \
- CONFIG_ARM64_PAN)); \
- } while (0)
-
+/*
+ * The Tag Check Flag (TCF) mode for MTE is per EL, hence TCF0
+ * affects EL0 and TCF affects EL1 irrespective of which TTBR is
+ * used.
+ * The kernel accesses TTBR0 usually with LDTR/STTR instructions
+ * when UAO is available, so these would act as EL0 accesses using
+ * TCF0.
+ * However futex.h code uses exclusives which would be executed as
+ * EL1, this can potentially cause a tag check fault even if the
+ * user disables TCF0.
+ *
+ * To address the problem we set the PSTATE.TCO bit in uaccess_enable()
+ * and reset it in uaccess_disable().
+ *
+ * The Tag check override (TCO) bit disables temporarily the tag checking
+ * preventing the issue.
+ */
- static inline void uaccess_disable(void)
+ static inline void uaccess_disable_privileged(void)
{
+ asm volatile(ALTERNATIVE("nop", SET_PSTATE_TCO(0),
+ ARM64_MTE, CONFIG_KASAN_HW_TAGS));
+
- __uaccess_disable(ARM64_HAS_PAN);
+ if (uaccess_ttbr0_disable())
+ return;
+
+ __uaccess_enable_hw_pan();
}
- static inline void uaccess_enable(void)
+ static inline void uaccess_enable_privileged(void)
{
+ asm volatile(ALTERNATIVE("nop", SET_PSTATE_TCO(1),
+ ARM64_MTE, CONFIG_KASAN_HW_TAGS));
+
- __uaccess_enable(ARM64_HAS_PAN);
- }
-
- /*
- * These functions are no-ops when UAO is present.
- */
- static inline void uaccess_disable_not_uao(void)
- {
- __uaccess_disable(ARM64_ALT_PAN_NOT_UAO);
- }
+ if (uaccess_ttbr0_enable())
+ return;
- static inline void uaccess_enable_not_uao(void)
- {
- __uaccess_enable(ARM64_ALT_PAN_NOT_UAO);
+ __uaccess_disable_hw_pan();
}
/*
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists