On Fri, 2021-12-03 at 16:33 +0000, Catalin Marinas wrote: > On Thu, Nov 25, 2021 at 06:19:29PM +0800, Yee Lee wrote: > > On Mon, 2021-08-02 at 16:30 +0100, Catalin Marinas wrote: > > > On Fri, Jul 30, 2021 at 10:49:53PM +0800, yee.lee@xxxxxxxxxxxx > > > wrote: > > > > From: Yee Lee <yee.lee@xxxxxxxxxxxx> > > > > > > > > For some low-end devices with limited resources, > > > > MTE needs to be optionally disabled to save system > > > > costs such as tag memory and firmware controls. > > > > > > I understand the cost of using MTE but I don't fully get what you > > > mean > > > by firmware controls. If the ID_AA64PFR1_EL1.MTE reports that MTE > > > is > > > present, the firmware should have initialised MTE correctly (e.g. > > > tag > > > allocation storage, SCR_EL3.ATA) and not rely on a kernel command > > > line > > > argument that may or may not be present. > > > > > > > This allows ID_AA64PFR1_EL1.MTE to be overridden on > > > > its shadow value by giving "arm64.nomte" on cmdline, > > > > and to suppress MTE feature. > > > > > > > > Suggested-by: Marc Zyngier <maz@xxxxxxxxxx> > > > > Suggested-by: Suzuki K Poulose <suzuki.poulose@xxxxxxx> > > > > Signed-off-by: Yee Lee <yee.lee@xxxxxxxxxxxx> > > > > > > While this patch appears to disable MTE, I don't think it can > > > fully > > > prevent the access to the allocation tag storage, so the firmware > > > must > > > still initialise it correctly. > > > > > > The issue is that __cpu_setup already configures the MAIR_EL1 > > > register > > > to use Normal Tagged memory for the kernel mapping and > > > SCTLR_EL1.ATA is > > > set. The TCF field is zero, so no tag checking, but I couldn't > > > figure > > > out from the ARM ARM whether this also prevents LDR/STR from > > > attempting > > > to fetch the allocation tags. I think it's only the ATA bit and > > > the MAIR > > > configuration. > > > > > > With this patch, KASAN_HW_TAGS (if configured) won't be used and > > > MTE > > > will not be presented to user applications, if that's what you > > > want, but > > > does not fully disable MTE. > > > > As pointed out earlier, the hardware has been verified that still > > has > > transaction sending to DRAM due to mair_el1(Normal_tagged) is > > setup. That means the override in this patch would be incompleted > > and > > cannot achieve to avoid undesired hardware confliction by disabling > > MTE. > > > > Do we have other options to delay the configuration on MAIR_EL1 > > after > > the override? Or maybe another CONFIG to bypass the init in > > __cpu_setup? > > This register is trickier as it may be cached in the TLB (IIRC). I > think > deferring the setting of SCTLR_EL1.ATA(0) should be sufficient. Can > you > try the diff I sent in the previous email and confirm that the > accesses > to the allocation tag storage are blocked? > Yes, the previous diff is already online. In our experiment, with cmdline, "arm64.nomte", cpu_enable_mte() is bypassed and the ATA0 is not set, but the access to tag memory still dispatches. Only as MAIR_EL1 remains MAIR_ATTR_NORMAL, instead of MAIR_ATTR_NORMAL_TAGGED, the access will stop. >From the manual, I think ATA only affects TAG instructions like STG, IRG, but not the tag access within normal STR/LDR.
