Re: [PATCH v7 18/29] arm64: mte: Allow user control of the tag check mode via prctl()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20/07/2020 18:00, Dave Martin wrote:
On Mon, Jul 20, 2020 at 04:30:35PM +0100, Kevin Brodsky wrote:
On 15/07/2020 18:08, Catalin Marinas wrote:
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@xxxxxxx>
Cc: Will Deacon <will@xxxxxxxxxx>
---

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.
[...]

diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
[...]

+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?

Isn't it as simple as checking if PF_KTHREAD is set in tsk->flags? At least this is what ssbs_thread_switch() does.

Kevin

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




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux