Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 8 Nov 2022 13:19:02 +0000
From:   Will Deacon <will@kernel.org>
To:     Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc:     linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        kasan-dev@googlegroups.com,
        Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH v2] mte: Initialize tag storage to KASAN_TAG_INVALID
Message-ID: <20221108131901.GA22816@willie-the-truck>
References: <20220907110015.11489-1-vincenzo.frascino@arm.com>
 <20221107151929.GB21002@willie-the-truck>
 <e1d857df-7b6b-113f-1bed-2b5274d887c1@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e1d857df-7b6b-113f-1bed-2b5274d887c1@arm.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Mon, Nov 07, 2022 at 04:47:14PM +0000, Vincenzo Frascino wrote:
> Hi Will,
> 
> On 11/7/22 15:19, Will Deacon wrote:
> > On Wed, Sep 07, 2022 at 12:00:15PM +0100, Vincenzo Frascino wrote:
> >> When the kernel is entered on aarch64, the MTE allocation tags are in an
> >> UNKNOWN state.
> >>
> >> With MTE enabled, the tags are initialized:
> >>  - When a page is allocated and the user maps it with PROT_MTE.
> >>  - On allocation, with in-kernel MTE enabled (HW_TAGS KASAN).
> >>
> >> If the tag pool is zeroed by the hardware at reset, it makes it
> >> difficult to track potential places where the initialization of the
> >> tags was missed.
> >>
> >> This can be observed under QEMU for aarch64, which initializes the MTE
> >> allocation tags to zero.
> >>
> >> Initialize to tag storage to KASAN_TAG_INVALID to catch potential
> >> places where the initialization of the tags was missed.
> >>
> >> This is done introducing a new kernel command line parameter
> >> "mte.tags_init" that enables the debug option.
> >>
> >> Note: The proposed solution should be considered a debug option because
> >> it might have performance impact on large machines at boot.
> >>
> >> Cc: Catalin Marinas <catalin.marinas@arm.com>
> >> Cc: Will Deacon <will@kernel.org>
> >> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> >> ---
> >>  arch/arm64/kernel/mte.c | 47 +++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 47 insertions(+)
> > 
> > I don't really see the point in this change -- who is going to use this
> > option?
> > 
> 
> I think this option can be useful to someone who is trying to debug a problem
> that is related to a missed tag initialization and it is doing it on QEMU.
> 
> QEMU by default would mask this class of problems because it initializes to zero
> the tags at "reset" (which is a valid UNKNOWN STATE according to the architecture).
> 
> I noticed this behavior because I was trying to debug a similar issue which I
> was able to reproduce only on FVP.
> 
> Said that, I originally posted this patch as RFC back in April this year to find
> out if someone else would find it useful, in fact my idea was to keep it locally.
> 
> Please let me know what do you want to do.

I'd prefer to leave the code as-is until we have a concrete ask for this
feature.

Will