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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60F3DC433ED for ; Wed, 7 Apr 2021 15:15:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2D3506139B for ; Wed, 7 Apr 2021 15:15:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353380AbhDGPPO (ORCPT ); Wed, 7 Apr 2021 11:15:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:34622 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232221AbhDGPPN (ORCPT ); Wed, 7 Apr 2021 11:15:13 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 17EB1611CC; Wed, 7 Apr 2021 15:15:00 +0000 (UTC) Date: Wed, 7 Apr 2021 16:14:58 +0100 From: Catalin Marinas To: Steven Price Cc: David Hildenbrand , Mark Rutland , Peter Maydell , "Dr. David Alan Gilbert" , Andrew Jones , Haibo Xu , Suzuki K Poulose , qemu-devel@nongnu.org, Marc Zyngier , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Dave Martin , James Morse , linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Will Deacon , kvmarm@lists.cs.columbia.edu, Julien Thierry Subject: Re: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature Message-ID: <20210407151458.GC21451@arm.com> References: <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com> <20210330103013.GD18075@arm.com> <8977120b-841d-4882-2472-6e403bc9c797@redhat.com> <20210331092109.GA21921@arm.com> <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com> <20210331184311.GA10737@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote: > On 31/03/2021 19:43, Catalin Marinas wrote: > > When a slot is added by the VMM, if it asked for MTE in guest (I guess > > that's an opt-in by the VMM, haven't checked the other patches), can we > > reject it if it's is going to be mapped as Normal Cacheable but it is a > > ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to > > check for ZONE_DEVICE)? This way we don't need to do more expensive > > checks in set_pte_at(). > > The problem is that KVM allows the VMM to change the memory backing a slot > while the guest is running. This is obviously useful for the likes of > migration, but ultimately means that even if you were to do checks at the > time of slot creation, you would need to repeat the checks at set_pte_at() > time to ensure a mischievous VMM didn't swap the page for a problematic one. Does changing the slot require some KVM API call? Can we intercept it and do the checks there? Maybe a better alternative for the time being is to add a new kvm_is_zone_device_pfn() and force KVM_PGTABLE_PROT_DEVICE if it returns true _and_ the VMM asked for MTE in guest. We can then only set PG_mte_tagged if !device. We can later relax this further to Normal Non-cacheable for ZONE_DEVICE memory (via a new KVM_PGTABLE_PROT_NORMAL_NC) or even Normal Cacheable if we manage to change the behaviour of the architecture. > > We could add another PROT_TAGGED or something which means PG_mte_tagged > > set but still mapped as Normal Untagged. It's just that we are short of > > pte bits for another flag. > > That could help here - although it's slightly odd as you're asking the > kernel to track the tags, but not allowing user space (direct) access to > them. Like you say using us the precious bits for this seems like it might > be short-sighted. Yeah, let's scrap this idea. We set PG_mte_tagged in user_mem_abort(), so we already know it's a page potentially containing tags. On restoring from swap, we need to check for MTE metadata irrespective of whether the user pte is tagged or not, as you already did in patch 1. I'll get back to that and look at the potential races. BTW, after a page is restored from swap, how long do we keep the metadata around? I think we can delete it as soon as it was restored and PG_mte_tagged was set. Currently it looks like we only do this when the actual page was freed or swapoff. I haven't convinced myself that it's safe to do this for swapoff unless it guarantees that all the ptes sharing a page have been restored. -- Catalin 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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D99C5C433ED for ; Wed, 7 Apr 2021 15:16:29 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7B0F9611CC for ; Wed, 7 Apr 2021 15:16:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B0F9611CC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:57584 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lU9uu-0001xr-IE for qemu-devel@archiver.kernel.org; Wed, 07 Apr 2021 11:16:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58166) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lU9tc-0001Kk-Px for qemu-devel@nongnu.org; Wed, 07 Apr 2021 11:15:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:51568) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lU9ta-0005Ba-HN for qemu-devel@nongnu.org; Wed, 07 Apr 2021 11:15:08 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 17EB1611CC; Wed, 7 Apr 2021 15:15:00 +0000 (UTC) Date: Wed, 7 Apr 2021 16:14:58 +0100 From: Catalin Marinas To: Steven Price Subject: Re: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature Message-ID: <20210407151458.GC21451@arm.com> References: <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com> <20210330103013.GD18075@arm.com> <8977120b-841d-4882-2472-6e403bc9c797@redhat.com> <20210331092109.GA21921@arm.com> <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com> <20210331184311.GA10737@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: pass client-ip=198.145.29.99; envelope-from=cmarinas@kernel.org; helo=mail.kernel.org X-Spam_score_int: -66 X-Spam_score: -6.7 X-Spam_bar: ------ X-Spam_report: (-6.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Peter Maydell , Andrew Jones , Haibo Xu , David Hildenbrand , Marc Zyngier , Suzuki K Poulose , Richard Henderson , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, Juan Quintela , James Morse , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, Thomas Gleixner , Julien Thierry , Will Deacon , Dave Martin , linux-kernel@vger.kernel.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote: > On 31/03/2021 19:43, Catalin Marinas wrote: > > When a slot is added by the VMM, if it asked for MTE in guest (I guess > > that's an opt-in by the VMM, haven't checked the other patches), can we > > reject it if it's is going to be mapped as Normal Cacheable but it is a > > ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to > > check for ZONE_DEVICE)? This way we don't need to do more expensive > > checks in set_pte_at(). > > The problem is that KVM allows the VMM to change the memory backing a slot > while the guest is running. This is obviously useful for the likes of > migration, but ultimately means that even if you were to do checks at the > time of slot creation, you would need to repeat the checks at set_pte_at() > time to ensure a mischievous VMM didn't swap the page for a problematic one. Does changing the slot require some KVM API call? Can we intercept it and do the checks there? Maybe a better alternative for the time being is to add a new kvm_is_zone_device_pfn() and force KVM_PGTABLE_PROT_DEVICE if it returns true _and_ the VMM asked for MTE in guest. We can then only set PG_mte_tagged if !device. We can later relax this further to Normal Non-cacheable for ZONE_DEVICE memory (via a new KVM_PGTABLE_PROT_NORMAL_NC) or even Normal Cacheable if we manage to change the behaviour of the architecture. > > We could add another PROT_TAGGED or something which means PG_mte_tagged > > set but still mapped as Normal Untagged. It's just that we are short of > > pte bits for another flag. > > That could help here - although it's slightly odd as you're asking the > kernel to track the tags, but not allowing user space (direct) access to > them. Like you say using us the precious bits for this seems like it might > be short-sighted. Yeah, let's scrap this idea. We set PG_mte_tagged in user_mem_abort(), so we already know it's a page potentially containing tags. On restoring from swap, we need to check for MTE metadata irrespective of whether the user pte is tagged or not, as you already did in patch 1. I'll get back to that and look at the potential races. BTW, after a page is restored from swap, how long do we keep the metadata around? I think we can delete it as soon as it was restored and PG_mte_tagged was set. Currently it looks like we only do this when the actual page was freed or swapoff. I haven't convinced myself that it's safe to do this for swapoff unless it guarantees that all the ptes sharing a page have been restored. -- Catalin 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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C624C433B4 for ; Wed, 7 Apr 2021 15:15:10 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 85740611CC for ; Wed, 7 Apr 2021 15:15:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 85740611CC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 297194B922; Wed, 7 Apr 2021 11:15:09 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+Adr2Ke9r5N; Wed, 7 Apr 2021 11:15:07 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id EA2CA4B911; Wed, 7 Apr 2021 11:15:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0EE1A4B904 for ; Wed, 7 Apr 2021 11:15:07 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgNZrfp-EZbS for ; Wed, 7 Apr 2021 11:15:05 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 16ADA4B903 for ; Wed, 7 Apr 2021 11:15:05 -0400 (EDT) Received: by mail.kernel.org (Postfix) with ESMTPSA id 17EB1611CC; Wed, 7 Apr 2021 15:15:00 +0000 (UTC) Date: Wed, 7 Apr 2021 16:14:58 +0100 From: Catalin Marinas To: Steven Price Subject: Re: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature Message-ID: <20210407151458.GC21451@arm.com> References: <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com> <20210330103013.GD18075@arm.com> <8977120b-841d-4882-2472-6e403bc9c797@redhat.com> <20210331092109.GA21921@arm.com> <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com> <20210331184311.GA10737@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Cc: David Hildenbrand , Marc Zyngier , Richard Henderson , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, Juan Quintela , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, Thomas Gleixner , Will Deacon , Dave Martin , linux-kernel@vger.kernel.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote: > On 31/03/2021 19:43, Catalin Marinas wrote: > > When a slot is added by the VMM, if it asked for MTE in guest (I guess > > that's an opt-in by the VMM, haven't checked the other patches), can we > > reject it if it's is going to be mapped as Normal Cacheable but it is a > > ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to > > check for ZONE_DEVICE)? This way we don't need to do more expensive > > checks in set_pte_at(). > > The problem is that KVM allows the VMM to change the memory backing a slot > while the guest is running. This is obviously useful for the likes of > migration, but ultimately means that even if you were to do checks at the > time of slot creation, you would need to repeat the checks at set_pte_at() > time to ensure a mischievous VMM didn't swap the page for a problematic one. Does changing the slot require some KVM API call? Can we intercept it and do the checks there? Maybe a better alternative for the time being is to add a new kvm_is_zone_device_pfn() and force KVM_PGTABLE_PROT_DEVICE if it returns true _and_ the VMM asked for MTE in guest. We can then only set PG_mte_tagged if !device. We can later relax this further to Normal Non-cacheable for ZONE_DEVICE memory (via a new KVM_PGTABLE_PROT_NORMAL_NC) or even Normal Cacheable if we manage to change the behaviour of the architecture. > > We could add another PROT_TAGGED or something which means PG_mte_tagged > > set but still mapped as Normal Untagged. It's just that we are short of > > pte bits for another flag. > > That could help here - although it's slightly odd as you're asking the > kernel to track the tags, but not allowing user space (direct) access to > them. Like you say using us the precious bits for this seems like it might > be short-sighted. Yeah, let's scrap this idea. We set PG_mte_tagged in user_mem_abort(), so we already know it's a page potentially containing tags. On restoring from swap, we need to check for MTE metadata irrespective of whether the user pte is tagged or not, as you already did in patch 1. I'll get back to that and look at the potential races. BTW, after a page is restored from swap, how long do we keep the metadata around? I think we can delete it as soon as it was restored and PG_mte_tagged was set. Currently it looks like we only do this when the actual page was freed or swapoff. I haven't convinced myself that it's safe to do this for swapoff unless it guarantees that all the ptes sharing a page have been restored. -- Catalin _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B180C433B4 for ; Wed, 7 Apr 2021 15:17:14 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CE83C61222 for ; Wed, 7 Apr 2021 15:17:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE83C61222 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; 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=pu5xBBDtgks8ukok0JOYuaO02JjiisSa+cMXHEykvTM=; b=Op9sqklLhI9rmLJ91SedobiFw P8HoCIrmENvyFzE1b5I4rl9KHPdY73IModj1+oYufiPASUdbdqKIHae7p2wVtTbd1ET34VyAvN8Gp aAMksQ7xRhCAv+dIGSgJALCC/NYuTkPF4kL3CDEaGVc0u+RLIJ85P11DQOkbTkMwbfrum34/sozYg wAKqQ1GDvD3T0Fu0AmtWmVek6NY3M84aTgjATywBLW68JmTin8zaTMOcVBUPyVDmixcBLT+UbEBEE ZTTcVs3X99N0iX0eDqEWnI1BG6aYSv6Wu9XZnlzmXnidotlPWRMeBq+PisyVq/ytsQBk7R0+0Ms7N gA36XTIeQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lU9th-005Fbv-WA; Wed, 07 Apr 2021 15:15:14 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lU9tZ-005FaM-KH for linux-arm-kernel@lists.infradead.org; Wed, 07 Apr 2021 15:15:07 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 17EB1611CC; Wed, 7 Apr 2021 15:15:00 +0000 (UTC) Date: Wed, 7 Apr 2021 16:14:58 +0100 From: Catalin Marinas To: Steven Price Cc: David Hildenbrand , Mark Rutland , Peter Maydell , "Dr. David Alan Gilbert" , Andrew Jones , Haibo Xu , Suzuki K Poulose , qemu-devel@nongnu.org, Marc Zyngier , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Dave Martin , James Morse , linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Will Deacon , kvmarm@lists.cs.columbia.edu, Julien Thierry Subject: Re: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature Message-ID: <20210407151458.GC21451@arm.com> References: <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com> <20210330103013.GD18075@arm.com> <8977120b-841d-4882-2472-6e403bc9c797@redhat.com> <20210331092109.GA21921@arm.com> <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com> <20210331184311.GA10737@arm.com> 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-20210407_161506_211911_F8F51775 X-CRM114-Status: GOOD ( 27.48 ) 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 Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote: > On 31/03/2021 19:43, Catalin Marinas wrote: > > When a slot is added by the VMM, if it asked for MTE in guest (I guess > > that's an opt-in by the VMM, haven't checked the other patches), can we > > reject it if it's is going to be mapped as Normal Cacheable but it is a > > ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to > > check for ZONE_DEVICE)? This way we don't need to do more expensive > > checks in set_pte_at(). > > The problem is that KVM allows the VMM to change the memory backing a slot > while the guest is running. This is obviously useful for the likes of > migration, but ultimately means that even if you were to do checks at the > time of slot creation, you would need to repeat the checks at set_pte_at() > time to ensure a mischievous VMM didn't swap the page for a problematic one. Does changing the slot require some KVM API call? Can we intercept it and do the checks there? Maybe a better alternative for the time being is to add a new kvm_is_zone_device_pfn() and force KVM_PGTABLE_PROT_DEVICE if it returns true _and_ the VMM asked for MTE in guest. We can then only set PG_mte_tagged if !device. We can later relax this further to Normal Non-cacheable for ZONE_DEVICE memory (via a new KVM_PGTABLE_PROT_NORMAL_NC) or even Normal Cacheable if we manage to change the behaviour of the architecture. > > We could add another PROT_TAGGED or something which means PG_mte_tagged > > set but still mapped as Normal Untagged. It's just that we are short of > > pte bits for another flag. > > That could help here - although it's slightly odd as you're asking the > kernel to track the tags, but not allowing user space (direct) access to > them. Like you say using us the precious bits for this seems like it might > be short-sighted. Yeah, let's scrap this idea. We set PG_mte_tagged in user_mem_abort(), so we already know it's a page potentially containing tags. On restoring from swap, we need to check for MTE metadata irrespective of whether the user pte is tagged or not, as you already did in patch 1. I'll get back to that and look at the potential races. BTW, after a page is restored from swap, how long do we keep the metadata around? I think we can delete it as soon as it was restored and PG_mte_tagged was set. Currently it looks like we only do this when the actual page was freed or swapoff. I haven't convinced myself that it's safe to do this for swapoff unless it guarantees that all the ptes sharing a page have been restored. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel