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();
}
/*
On Thu, Dec 03, 2020 at 07:06:01PM +1100, Stephen Rothwell wrote:
> 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();
> }
>
> /*
Thanks Stephen, it looks fine. I may clean it up a bit with dedicated
functions for the asm statements but after -rc1.
--
Catalin
On Tue, Apr 13, 2021 at 06:59:36PM +1000, Stephen Rothwell wrote:
> diff --cc lib/test_kasan.c
> index 785e724ce0d8,bf9225002a7e..000000000000
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@@ -78,33 -83,30 +83,35 @@@ static void kasan_test_exit(struct kuni
> * fields, it can reorder or optimize away the accesses to those fields.
> * Use READ/WRITE_ONCE() for the accesses and compiler barriers around the
> * expression to prevent that.
> + *
> + * In between KUNIT_EXPECT_KASAN_FAIL checks, fail_data.report_found is kept as
> + * false. This allows detecting KASAN reports that happen outside of the checks
> + * by asserting !fail_data.report_found at the start of KUNIT_EXPECT_KASAN_FAIL
> + * and in kasan_test_exit.
> */
> - #define KUNIT_EXPECT_KASAN_FAIL(test, expression) do { \
> - if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) && \
> - !kasan_async_mode_enabled()) \
> - migrate_disable(); \
> - WRITE_ONCE(fail_data.report_expected, true); \
> - WRITE_ONCE(fail_data.report_found, false); \
> - kunit_add_named_resource(test, \
> - NULL, \
> - NULL, \
> - &resource, \
> - "kasan_data", &fail_data); \
> - barrier(); \
> - expression; \
> - barrier(); \
> - if (kasan_async_mode_enabled()) \
> - kasan_force_async_fault(); \
> - barrier(); \
> - KUNIT_EXPECT_EQ(test, \
> - READ_ONCE(fail_data.report_expected), \
> - READ_ONCE(fail_data.report_found)); \
> - if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) && \
> - !kasan_async_mode_enabled()) { \
> - if (READ_ONCE(fail_data.report_found)) \
> - kasan_enable_tagging_sync(); \
> - migrate_enable(); \
> - } \
> + #define KUNIT_EXPECT_KASAN_FAIL(test, expression) do { \
> - if (IS_ENABLED(CONFIG_KASAN_HW_TAGS)) \
> ++ if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) && \
> ++ !kasan_async_mode_enabled()) \
> + migrate_disable(); \
> + KUNIT_EXPECT_FALSE(test, READ_ONCE(fail_data.report_found)); \
> + WRITE_ONCE(fail_data.report_expected, true); \
> + barrier(); \
> + expression; \
> + barrier(); \
> ++ if (kasan_async_mode_enabled()) \
> ++ kasan_force_async_fault(); \
> ++ barrier(); \
> + KUNIT_EXPECT_EQ(test, \
> + READ_ONCE(fail_data.report_expected), \
> + READ_ONCE(fail_data.report_found)); \
> - if (IS_ENABLED(CONFIG_KASAN_HW_TAGS)) { \
> ++ if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) && \
> ++ !kasan_async_mode_enabled()) { \
> + if (READ_ONCE(fail_data.report_found)) \
> - kasan_enable_tagging(); \
> ++ kasan_enable_tagging_sync(); \
> + migrate_enable(); \
> + } \
> + WRITE_ONCE(fail_data.report_found, false); \
> + WRITE_ONCE(fail_data.report_expected, false); \
> } while (0)
>
> #define KASAN_TEST_NEEDS_CONFIG_ON(test, config) do { \
Thanks Stephen. The resolution looks correct.
Andrew, if you'd rather I dropped the MTE async mode support from the
arm64 tree please let me know. Thanks.
https://lore.kernel.org/r/[email protected]/
--
Catalin