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:

quoted

On Mon, 2021-08-02 at 16:30 +0100, Catalin Marinas wrote:

quoted

On Fri, Jul 30, 2021 at 10:49:53PM +0800, yee.lee@mediatek.com
wrote:

quoted

From: Yee Lee <redacted>

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.

quoted

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@kernel.org>
Suggested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Yee Lee <redacted>

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.