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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9574EC433EF for ; Wed, 30 Mar 2022 16:18:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 106226B0073; Wed, 30 Mar 2022 12:18:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B5F46B0074; Wed, 30 Mar 2022 12:18:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E711F8D0001; Wed, 30 Mar 2022 12:18:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0092.hostedemail.com [216.40.44.92]) by kanga.kvack.org (Postfix) with ESMTP id D94BA6B0073 for ; Wed, 30 Mar 2022 12:18:21 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9313B8248D52 for ; Wed, 30 Mar 2022 16:18:21 +0000 (UTC) X-FDA: 79301560002.18.B04C93C Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf16.hostedemail.com (Postfix) with ESMTP id 3311618001C for ; Wed, 30 Mar 2022 16:18:21 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id jx9so21107798pjb.5 for ; Wed, 30 Mar 2022 09:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=nLFu3lC46wywpXjsuIK0ZHIhaIdPVQVthjLJWcG1bqs=; b=ObdhiCZmnQ357m81FhFtTehR9aYW6P4+BOjn381CbSMHEsU1E7K3XcewtQe3sJCPWQ Csyxq34Lypg3+bYvidjj+H3qoa/rNI7SuZbTd3AoCwOk6Mqd2uRtxKjVcVzSJoZodMTf D/y6FT6RGJsMSbkAlI8a0sPYLgZwkMMWyNwRd4fxHKehurrHJxHet0aUP9LncDJtE3cQ UPOz+IFAmZ6u0RgCGDhAInm8qhjfecUTWrGa0uueQmXiVf0afirovk1cfrPKwTF9EAHS gOr/NoP4PJTR2EKpDT/fo37IVT+5E6uWqx4jWGTeL/5PLf3qFXEVzRH+FzhiYJwPOXLr Ejdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nLFu3lC46wywpXjsuIK0ZHIhaIdPVQVthjLJWcG1bqs=; b=X+dgbcavdZcg4Lk05oHSYN4SVo0BfpjYr6ePF8mrDFSemnpNguIHh+VMPr37lMeWS4 IoxiLwpf6GYq7F8WqrQERpsR0ar0G1PpZgi3vtNMldomDv91DAZaenz8++y6fEBIJAD2 cLRbbqbQ6hQj902Kmhbiz3yWXt4VZQxGzFVvFxMxEu3khxcI/H6vW5B4BOcs2yFetZ2z zQF6g37q95Tmk3/a6/ohlmfX8Co0gWhElqd0pl+a3Qw9AZKql4yExzsRzzj+9ZKAecp3 vB0CRLNlhwLoFBgafnPARRdxAxo2QqOhyyXPjYYLLvkuJXaBjEbD8AawP1Qn8H53rpT/ 4tAQ== X-Gm-Message-State: AOAM532n+7JoI6zlgsTSQXWRDg12wuxbWj+DLnIddofoZvsD3ZHxJQ6J FPi4PXu/dYT1/PYlwrHmsrIadg== X-Google-Smtp-Source: ABdhPJzu0B5xizLOKCwUOp7QXz7jXFJn2pPNsklxdxdBWzWCsDjkD8HDdgo8h4C6dlF1WJ0c8QhdzA== X-Received: by 2002:a17:903:2305:b0:154:4aa2:e800 with SMTP id d5-20020a170903230500b001544aa2e800mr29560plh.167.1648657099936; Wed, 30 Mar 2022 09:18:19 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id b14-20020a056a000cce00b004fabc39519esm25365204pfv.5.2022.03.30.09.18.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Mar 2022 09:18:19 -0700 (PDT) Date: Wed, 30 Mar 2022 16:18:15 +0000 From: Sean Christopherson To: Steven Price Cc: Quentin Perret , Chao Peng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Mike Rapoport , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, maz@kernel.org, will@kernel.org Subject: Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory Message-ID: References: <20220310140911.50924-1-chao.p.peng@linux.intel.com> <88620519-029e-342b-0a85-ce2a20eaf41b@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <88620519-029e-342b-0a85-ce2a20eaf41b@arm.com> Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ObdhiCZm; spf=pass (imf16.hostedemail.com: domain of seanjc@google.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 3311618001C X-Stat-Signature: umc4sjkt49gwsz7ddjh8gwoyotnefgdo X-HE-Tag: 1648657101-244477 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Mar 30, 2022, Steven Price wrote: > On 29/03/2022 18:01, Quentin Perret wrote: > > Is implicit sharing a thing? E.g., if a guest makes a memory access in > > the shared gpa range at an address that doesn't have a backing memslot, > > will KVM check whether there is a corresponding private memslot at the > > right offset with a hole punched and report a KVM_EXIT_MEMORY_ERROR? Or > > would that just generate an MMIO exit as usual? > > My understanding is that the guest needs some way of tagging whether a > page is expected to be shared or private. On the architectures I'm aware > of this is done by effectively stealing a bit from the IPA space and > pretending it's a flag bit. > > So when a guest access causes a fault, the flag bit (really part of the > intermediate physical address) is compared against whether the page is > present in the private fd. If they correspond (i.e. a private access and > the private fd has a page, or a shared access and there's a hole in the > private fd) then the appropriate page is mapped and the guest continues. > If there's a mismatch then a KVM_EXIT_MEMORY_ERROR exit is trigged and > the VMM is expected to fix up the situation (either convert the page or > kill the guest if this was unexpected). x86 architectures do steal a bit, but it's not strictly required. The guest can communicate its desired private vs. shared state via hypercall. I refer to the hypercall method as explicit conversion, and reacting to a page fault due to accessing the "wrong" PA variant as implicit conversion. I have dreams of supporting a software-only implementation on x86, a la pKVM, if only for testing and debug purposes. In that case, only explicit conversion is supported. I'd actually prefer TDX and SNP only allow explicit conversion, i.e. let the host treat accesses to the "wrong" PA as illegal, but sadly the guest/host ABIs for both TDX and SNP require the host to support implicit conversions. > >>>> The key point is that KVM never decides to convert between shared and private, it's > >>>> always a userspace decision. Like normal memslots, where userspace has full control > >>>> over what gfns are a valid, this gives userspace full control over whether a gfn is > >>>> shared or private at any given time. > >>> > >>> I'm understanding this as 'the VMM is allowed to punch holes in the > >>> private fd whenever it wants'. Is this correct? > >> > >> From the kernel's perspective, yes, the VMM can punch holes at any time. From a > >> "do I want to DoS my guest" perspective, the VMM must honor its contract with the > >> guest and not spuriously unmap private memory. > >> > >>> What happens if it does so for a page that a guest hasn't shared back? > >> > >> When the hole is punched, KVM will unmap the corresponding private SPTEs. If the > >> guest is still accessing the page as private, the next access will fault and KVM > >> will exit to userspace with KVM_EXIT_MEMORY_ERROR. Of course the guest is probably > >> hosed if the hole punch was truly spurious, as at least hardware-based protected VMs > >> effectively destroy data when a private page is unmapped from the guest private SPTEs. > >> > >> E.g. Linux guests for TDX and SNP will panic/terminate in such a scenario as they > >> will get a fault (injected by trusted hardware/firmware) saying that the guest is > >> trying to access an unaccepted/unvalidated page (TDX and SNP require the guest to > >> explicit accept all private pages that aren't part of the guest's initial pre-boot > >> image). > > > > I suppose this is necessary is to prevent the VMM from re-fallocating > > in a hole it previously punched and re-entering the guest without > > notifying it? > > I don't know specifically about TDX/SNP, but one thing we want to > prevent with CCA is the VMM deallocating/reallocating a private page > without the guest being aware (i.e. corrupting the guest's state).So > punching a hole will taint the address such that a future access by the > guest is fatal (unless the guest first jumps through the right hoops to > acknowledge that it was expecting such a thing). Yep, both TDX and SNP will trigger a fault in the guest if the host removes and reinserts a private page. The current plan for Linux guests is to track whether or not a given page has been accepted as private, and panic/die if a fault due to unaccepted private page occurs.