Messages in this thread | | | Date | Tue, 8 Nov 2022 13:19:02 +0000 | From | Will Deacon <> | Subject | Re: [PATCH v2] mte: Initialize tag storage to KASAN_TAG_INVALID |
| |
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
| |