From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 70357C4332F for ; Tue, 8 Nov 2022 13:20:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8lY2+936VW4heJdN2cNpEydVXUtlL/1QV8FO6vg0bzg=; b=kv+jR7jhBRYFD6 wtnSVj9pjepRMEQ4peEH8BG/i+ip7zBYhdlmMNPNuQ2PJfq/vHxjm9wlYHaq5CNxhfXaXoLNdymQF WHM+MDP6g7WRgy0ibm+tHKXALScz6LKk9f5rbkUY68P77nck+WdP/R+d25e53xSKfmnZA++AWTQcO 731JaUg1Y3LukQYEhS9zFWxQcnDjYvKd0oTY4bDldzRNCuz9IVMu2AZyqWqr650Wx0/FeoXrWNEgD tmOBbUAV+5R3dYV4nVxdeCXM2Xo0mBRLyfCiQLkGrN4ud63m6czM3T4EDmTk7DrNQRRzZckdQx3hP 6I26Ik0tr/28OlFcqf+Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1osOVV-005YhM-5h; Tue, 08 Nov 2022 13:19:13 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1osOVR-005Yfy-Ru for linux-arm-kernel@lists.infradead.org; Tue, 08 Nov 2022 13:19:11 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 708286148D; Tue, 8 Nov 2022 13:19:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C35EBC433C1; Tue, 8 Nov 2022 13:19:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1667913547; bh=8YhLs6Xl5Z3PNK4uEBuLitnKdiZ0d1Z9zfNCnk9Xdjk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nwQxPA0g+qX1N5tSZyFG9gTNM+O2dXsM/OsmQp7/8BlYQkin6Hqvev5f32r1rcRgg rri6SeKVUU2Z8mwHLvGqTdS4gKFphw79zBWbF6r8dyKGtRJJoqdP2T1B5XATZBsyLc G4vMWm5GU2geUpECpMVKngqQfCeUpwIhLWpEE/khygQ3fXUwZwuJrcovy7KshIiz7e tulhpg7OTGzGlI2op7vmOZsitZxuJZyiFovRi9ikZLNvcYv5AtZbaggiL6kapa8xn9 G2ypHhHgy2C193RH8wMfM1zQCPPxQ36WHjTf8XdruXWmC4Pi8qwayUTJxZgOG1Yi0n dMCV4eKMBcVCw== Date: Tue, 8 Nov 2022 13:19:02 +0000 From: Will Deacon To: Vincenzo Frascino Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Catalin Marinas 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221108_051909_987469_F6A740DA X-CRM114-Status: GOOD ( 35.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 > >> Cc: Will Deacon > >> Signed-off-by: Vincenzo Frascino > >> --- > >> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel