linux-kernel - Re: [PATCH v3 1/1] arm64/cpufeature: Optionally disable MTE via command-line

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YapGyozjactAm8vp@arm.com>
Date:   Fri, 3 Dec 2021 16:33:14 +0000
From:   Catalin Marinas <catalin.marinas@....com>
To:     Yee Lee <yee.lee@...iatek.com>
Cc:     linux-kernel@...r.kernel.org, nicholas.Tang@...iatek.com,
        Kuan-Ying.lee@...iatek.com, chinwen.chang@...iatek.com,
        Jonathan Corbet <corbet@....net>,
        Will Deacon <will@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Maciej W. Rozycki" <macro@...am.me.uk>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Marc Zyngier <maz@...nel.org>,
        David Brazdil <dbrazdil@...gle.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Fuad Tabba <tabba@...gle.com>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" 
        <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>
Subject: Re: [PATCH v3 1/1] arm64/cpufeature: Optionally disable MTE via
 command-line

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@...iatek.com wrote:
> > > From: Yee Lee <yee.lee@...iatek.com>
> > > 
> > > 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@...nel.org>
> > > Suggested-by: Suzuki K Poulose <suzuki.poulose@....com>
> > > Signed-off-by: Yee Lee <yee.lee@...iatek.com>
> > 
> > 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