[PATCH v11 4/5] arm64: mte: Enable async tag check fault
Catalin Marinas
catalin.marinas at arm.com
Fri Feb 5 10:39:19 EST 2021
On Sat, Jan 30, 2021 at 04:52:24PM +0000, Vincenzo Frascino wrote:
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index 92078e1eb627..7763ac1f2917 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -182,6 +182,37 @@ bool mte_report_once(void)
> return READ_ONCE(report_fault_once);
> }
>
> +#ifdef CONFIG_KASAN_HW_TAGS
> +void mte_check_tfsr_el1(void)
> +{
> + u64 tfsr_el1;
> +
> + if (!system_supports_mte())
> + return;
> +
> + tfsr_el1 = read_sysreg_s(SYS_TFSR_EL1);
> +
> + /*
> + * The kernel should never trigger an asynchronous fault on a
> + * TTBR0 address, so we should never see TF0 set.
> + * For futexes we disable checks via PSTATE.TCO.
> + */
> + WARN_ONCE(tfsr_el1 & SYS_TFSR_EL1_TF0,
> + "Kernel async tag fault on TTBR0 address");
Sorry, I got confused when I suggested this warning. If the user is
running in async mode, the TFSR_EL1.TF0 bit may be set by
copy_mount_options(), strncpy_from_user() which rely on an actual fault
happening (not the case with asynchronous where only a bit is set). With
the user MTE support, we never report asynchronous faults caused by the
kernel on user addresses as we can't easily track them. So this warning
may be triggered on correctly functioning kernel/user.
> +
> + if (unlikely(tfsr_el1 & SYS_TFSR_EL1_TF1)) {
> + /*
> + * Note: isb() is not required after this direct write
> + * because there is no indirect read subsequent to it
> + * (per ARM DDI 0487F.c table D13-1).
> + */
> + write_sysreg_s(0, SYS_TFSR_EL1);
Zeroing the whole register is still fine, we don't care about the TF0
bit anyway.
> +
> + kasan_report_async();
> + }
> +}
> +#endif
--
Catalin
More information about the linux-arm-kernel
mailing list