Re: [PATCH v7 18/29] arm64: mte: Allow user control of the tag check mode via prctl()
From: Dave Martin <Dave.Martin@arm.com>
Date: 2020-07-20 17:11:07
Also in:
linux-arm-kernel, linux-mm
On Mon, Jul 20, 2020 at 04:30:35PM +0100, Kevin Brodsky wrote:
On 15/07/2020 18:08, Catalin Marinas wrote:quoted
By default, even if PROT_MTE is set on a memory range, there is no tag check fault reporting (SIGSEGV). Introduce a set of option to the exiting prctl(PR_SET_TAGGED_ADDR_CTRL) to allow user control of the tag check fault mode: PR_MTE_TCF_NONE - no reporting (default) PR_MTE_TCF_SYNC - synchronous tag check fault reporting PR_MTE_TCF_ASYNC - asynchronous tag check fault reporting These options translate into the corresponding SCTLR_EL1.TCF0 bitfield, context-switched by the kernel. Note that uaccess done by the kernel is not checked and cannot be configured by the user. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> --- Notes: v3: - Use SCTLR_EL1_TCF0_NONE instead of 0 for consistency. - Move mte_thread_switch() in this patch from an earlier one. In addition, it is called after the dsb() in __switch_to() so that any asynchronous tag check faults have been registered in the TFSR_EL1 registers (to be added with the in-kernel MTE support. v2: - Handle SCTLR_EL1_TCF0_NONE explicitly for consistency with PR_MTE_TCF_NONE. - Fix SCTLR_EL1 register setting in flush_mte_state() (thanks to Peter Collingbourne). - Added ISB to update_sctlr_el1_tcf0() since, with the latest architecture update/fix, the TCF0 field is used by the uaccess routines.
[...]
quoted
diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
[...]
quoted
+void mte_thread_switch(struct task_struct *next) +{ + if (!system_supports_mte()) + return; + + /* avoid expensive SCTLR_EL1 accesses if no change */ + if (current->thread.sctlr_tcf0 != next->thread.sctlr_tcf0)I think this could be improved by checking whether `next` is a kernel thread, in which case thread.sctlr_tcf0 is 0 but there is no point in setting SCTLR_EL1.TCF0, since there should not be any access via TTBR0.
Out of interest, do we have a nice way of testing for a kernel thread now? I remember fpsimd_thread_switch() used to check for task->mm, but we seem to have got rid of that at some point. set_mm() can defeat this, and anyway the heavy lifting for FPSIMD is now deferred until returning to userspace. Cheers ---Dave