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