Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1852795pxb; Sat, 14 Nov 2020 04:46:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJykDUZMhF5FSZXxAs5MEGV64vA/3ebvBYk9VBbf4J/Oo80AGlXeGun7q+8JJwE9ScWGMNWE X-Received: by 2002:a17:906:b255:: with SMTP id ce21mr6749437ejb.137.1605358019381; Sat, 14 Nov 2020 04:46:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605358019; cv=none; d=google.com; s=arc-20160816; b=iUQuGy4CmV92BOFbUh2YDAtt1Jtjup28jsLDCmV32klNBekXCapRbzua4rNxpwV1lf 1RP5KH8M4qNWinvRF00soAKyZ2P6YcLVKhTJX0nu6YDDnCoShhRSusyJyN+X5vJt2ETR 29Ht9USKyhOI/YXR550MYsmmKhek4MWKdcV8iNHUCR0z0d8hflMV30fKvBPpsZ6oUnRx 3Ibj+VaZZBmmpUEGiC99y44ir/vONgbT027uvmmhrlVJl2EGUWN1CqEVn5R5McPFyaMe UM1nVTFMVDH9M/MVFD9CdwJ8upTNFNKwstVez+3W9RJfrkPzc8fa3ZaE0wypBZUPLPBK FDxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=9TcHEhhPt8WFSqyJdv7UhW23Nxn3ENvAZaNdkv+kgu4=; b=GCVjuZF5xY4NMwB+rLD0UZWNxdABRO0prZBvMNbUaG1ozIk214NkTGwZDsADl91/Vg rtvwtcxHwf0XeOhZhKXIXHCcES6du6phnqMVB7trx62eVOj4WkafDjKwP8ex+YDqvctd fn76zrSFbfjoBVnYcbRH2hcK0ZeM3upPJxO+8JbaNSBQGZMyMrd+ejl2fnCxqbyRrcxm FCNx1dm2ekhWaGAUb9n/El44JL5CpD8ub15aSqUanjpRmzgK3nCqEZP7DacIdrzJEoQT dglDjJaRe5JDP5Vln4DiTlp0AM4RmD0hrhB+FjHfOA9SWQ9uMUdbXG7J5jQ5FpXVsEiI phZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b26si8602598edy.172.2020.11.14.04.46.37; Sat, 14 Nov 2020 04:46:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726593AbgKNMnw (ORCPT + 99 others); Sat, 14 Nov 2020 07:43:52 -0500 Received: from mail.kernel.org ([198.145.29.99]:40686 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726112AbgKNMnv (ORCPT ); Sat, 14 Nov 2020 07:43:51 -0500 Received: from gaia (unknown [2.26.170.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1FFF720759; Sat, 14 Nov 2020 12:43:48 +0000 (UTC) Date: Sat, 14 Nov 2020 12:43:46 +0000 From: Catalin Marinas To: Andrey Konovalov Cc: Andrew Morton , Will Deacon , Vincenzo Frascino , Dmitry Vyukov , Andrey Ryabinin , Alexander Potapenko , Marco Elver , Evgenii Stepanov , Branislav Rankov , Kevin Brodsky , kasan-dev@googlegroups.com, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH mm v10 26/42] arm64: mte: Reset the page tag in page->flags Message-ID: <20201114124346.GC2837@gaia> References: <18bca1ff61bf6605289e7213153b3fd5b8f81e27.1605305705.git.andreyknvl@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18bca1ff61bf6605289e7213153b3fd5b8f81e27.1605305705.git.andreyknvl@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 13, 2020 at 11:15:54PM +0100, Andrey Konovalov wrote: > From: Vincenzo Frascino > > The hardware tag-based KASAN for compatibility with the other modes > stores the tag associated to a page in page->flags. > Due to this the kernel faults on access when it allocates a page with an > initial tag and the user changes the tags. > > Reset the tag associated by the kernel to a page in all the meaningful > places to prevent kernel faults on access. > > Note: An alternative to this approach could be to modify page_to_virt(). > This though could end up being racy, in fact if a CPU checks the > PG_mte_tagged bit and decides that the page is not tagged but another > CPU maps the same with PROT_MTE and becomes tagged the subsequent kernel > access would fail. > > Signed-off-by: Vincenzo Frascino > Signed-off-by: Andrey Konovalov Reviewed-by: Catalin Marinas