Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1670254pxf; Fri, 26 Mar 2021 12:00:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz0RkVsXmFL/vfDruRzCuMu8s4oAlqu+b7HgATYRVtxJRr057jfvYpHIwFD089nGeYreLrp X-Received: by 2002:a17:907:d1f:: with SMTP id gn31mr16748945ejc.536.1616785258021; Fri, 26 Mar 2021 12:00:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616785258; cv=none; d=google.com; s=arc-20160816; b=RzsydzL9JInxgoAvLdRkBaJrrhiImE0KWfBbohP1XzmI3uPRKs5UXZuz23YpB+G0mK GykIqAimajbl4uP7TdqweSXR7Acs3sY++ufiak+dPBxTviwOsFblff793loYHN86Azeo tjXpcEajnb/IDhEOsxbWVchGjPTW8JVPuasHvaE3tTnOzwXczpstyW6qZcew/kKN1WQq IiKw20NDkK73JSdwUlor2kd5GnN1u9VH3nuOjOpPvmhuK3hJX/Q7VUDOD5WQM701r1t2 5U8NOxRgk3wsw4d7vF2C9Dycngg8KCjRZpk7cnePprlt+2ViNv0ybUsUzVYOG0MHUKp4 nyMw== 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=eqENJtYBkHirdyRkqGy7jlHdYPx253H1Bl8K8z3BcFA=; b=K0gFWOtcaF/fUx3TNGLQe6wdNpHzo0zYtZU89jujtCMJc/wxAEg00S9c3HTUgBfWXr V0OQ1ajrZeyYzcGViOycNkIOnoxOU6JP62HIfBWT/hs/Nd4Yd6RbFOqRyW5uYQNkwFIR BWrQhv0fVf8gDazYX94LLrqkx7RhX6zZAPubFYQf35VOIRknfVw55b89xyyY0BanGiEg Ol1IRr41Kx878pzNYsnKPZaNqQ89JL1YuSMxJ1colQIjMcFn5cUSf8eobpWBp2dqdNLO GylH1tAd9p+GdNI84V1yfds4XikKHfpxB3GUodpQVNv2u1lYugkUIGrzhFKDikGArVpz g7LQ== 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 b25si7362839ejv.506.2021.03.26.12.00.35; Fri, 26 Mar 2021 12:00:58 -0700 (PDT) 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 S230138AbhCZS5V (ORCPT + 99 others); Fri, 26 Mar 2021 14:57:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:42976 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230194AbhCZS5A (ORCPT ); Fri, 26 Mar 2021 14:57:00 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9F6AA619F7; Fri, 26 Mar 2021 18:56:56 +0000 (UTC) Date: Fri, 26 Mar 2021 18:56:54 +0000 From: Catalin Marinas To: Steven Price Cc: Marc Zyngier , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave Martin , Mark Rutland , Thomas Gleixner , qemu-devel@nongnu.org, Juan Quintela , "Dr. David Alan Gilbert" , Richard Henderson , Peter Maydell , Haibo Xu , Andrew Jones Subject: Re: [PATCH v10 1/6] arm64: mte: Sync tags for pages where PTE is untagged Message-ID: <20210326185653.GG5126@arm.com> References: <20210312151902.17853-1-steven.price@arm.com> <20210312151902.17853-2-steven.price@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210312151902.17853-2-steven.price@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Steven, On Fri, Mar 12, 2021 at 03:18:57PM +0000, Steven Price wrote: > A KVM guest could store tags in a page even if the VMM hasn't mapped > the page with PROT_MTE. So when restoring pages from swap we will > need to check to see if there are any saved tags even if !pte_tagged(). > > However don't check pages which are !pte_valid_user() as these will > not have been swapped out. > > Signed-off-by: Steven Price > --- > arch/arm64/include/asm/pgtable.h | 2 +- > arch/arm64/kernel/mte.c | 16 ++++++++++++---- > 2 files changed, 13 insertions(+), 5 deletions(-) > > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > index e17b96d0e4b5..84166625c989 100644 > --- a/arch/arm64/include/asm/pgtable.h > +++ b/arch/arm64/include/asm/pgtable.h > @@ -312,7 +312,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr, > __sync_icache_dcache(pte); > > if (system_supports_mte() && > - pte_present(pte) && pte_tagged(pte) && !pte_special(pte)) > + pte_present(pte) && pte_valid_user(pte) && !pte_special(pte)) > mte_sync_tags(ptep, pte); With the EPAN patches queued in for-next/epan, pte_valid_user() disappeared as its semantics weren't very clear. So this relies on the set_pte_at() being done on the VMM address space. I wonder, if the VMM did an mprotect(PROT_NONE), can the VM still access it via stage 2? If yes, the pte_valid_user() test wouldn't work. We need something like pte_present() && addr <= user_addr_max(). BTW, ignoring virtualisation, can we ever bring a page in from swap on a PROT_NONE mapping (say fault-around)? It's not too bad if we keep the metadata around for when the pte becomes accessible but I suspect we remove it if the page is removed from swap. -- Catalin