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 457E9C433EF for ; Mon, 28 Mar 2022 18:01:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A70F8D0002; Mon, 28 Mar 2022 14:01:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8568B8D0001; Mon, 28 Mar 2022 14:01:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F7848D0002; Mon, 28 Mar 2022 14:01:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id 5F0CE8D0001 for ; Mon, 28 Mar 2022 14:01:08 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1DDBAA4A5E for ; Mon, 28 Mar 2022 18:01:08 +0000 (UTC) X-FDA: 79294561416.24.5C695BB Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by imf13.hostedemail.com (Postfix) with ESMTP id CEA082004E for ; Mon, 28 Mar 2022 18:01:05 +0000 (UTC) Received: by mail-wr1-f54.google.com with SMTP id h4so21491096wrc.13 for ; Mon, 28 Mar 2022 11:01:05 -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=ytrSkwXUDSFcv9NwzDcZHJvhwX8Ip28tSIzF/72ZJ1Q=; b=VcyTOLVPq+V1OSY1Zl84llZUOW1+DiM07S87IWjY6+20V2jBdQ1vm+S2GV9qIJPtqv pLK4CJ9etgGbTHFOsHk97o/HxvnmIVI4mMk+EGHbRX6CJrIFhyvnSC6Rfimd+X/hl2uA a6RBgH4fTtSovkIx/LH5QsjPzVnFtvX03n05rdHb2Niy7y93hqADUsfUaEgwWTWY0DGl GeMqskNlS97LRMAsvI02JTysyyghYlfjb9mf6gG4HlbTYhYnGIBhn3XdBYfTYXBaOwsF 95L6ejUjlhIht89eN92IqbUGGnk20Xbj3EaFlV+lYxgRhw/js5pXwNxfvBz/LaSuxyZ9 fpdA== 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=ytrSkwXUDSFcv9NwzDcZHJvhwX8Ip28tSIzF/72ZJ1Q=; b=3P2QFS7gC4cWAjTm0iGclPkFnkZdn0dGLbMCqe1bUWEpn7d2t5tOL158fbN93XGHus f3qrfAQGx2Mk6eDYQIqUdZkKmikaWYCigyAufXxEHvDaPgeYCg6ntUe8R/Wnsh5C3Il9 sNCMIa0abJ18yTjHTKVJqLZVDdQjsEpT/iN+C8StK0dk+YuB52SHbaylDTqfWJ+sTYWv rQ1hE+XanqGv09YPo+nVI5KNuMkpM4Bgu9RRRirpfHrQehzBhCSESVxCobdrnIYyEmXW Refcz7SQHgyK92aWn8XtwbR9NyTXxPeIH46geRH0oZDn+fGKjjoa1ylql6VA6E5Gds/c im9A== X-Gm-Message-State: AOAM53235KSc2evd+P4K8iqcrB560+taXy9LF0F9NbTuD6NNLfRhFK2l 4m0RFMEEBYjQTTY95YzVcLY6Jw== X-Google-Smtp-Source: ABdhPJz/DFJ+XVXhJNrPMlWXh7xu5l3qH4Q/QymhLpFp1U0q32kHVhkRByS9xkteULaLyJt8VbhF/w== X-Received: by 2002:adf:fac8:0:b0:203:fb08:ff7 with SMTP id a8-20020adffac8000000b00203fb080ff7mr24674238wrs.648.1648490463028; Mon, 28 Mar 2022 11:01:03 -0700 (PDT) Received: from google.com ([2a00:79e0:d:210:2cfc:d300:5bbc:f8a0]) by smtp.gmail.com with ESMTPSA id bi20-20020a05600c3d9400b0038cfe80eeddsm142468wmb.29.2022.03.28.11.01.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Mar 2022 11:01:02 -0700 (PDT) Date: Mon, 28 Mar 2022 19:00:58 +0100 From: Quentin Perret To: Sean Christopherson Cc: 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 , Steven Price , "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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: 8b6rqx8pfs8ubfuwn3wd8kmfmx6j6ea3 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=VcyTOLVP; spf=pass (imf13.hostedemail.com: domain of qperret@google.com designates 209.85.221.54 as permitted sender) smtp.mailfrom=qperret@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: CEA082004E X-HE-Tag: 1648490465-153844 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: Hi Sean, Thanks for the reply, this helps a lot. On Monday 28 Mar 2022 at 17:13:10 (+0000), Sean Christopherson wrote: > On Thu, Mar 24, 2022, Quentin Perret wrote: > > For Protected KVM (and I suspect most other confidential computing > > solutions), guests have the ability to share some of their pages back > > with the host kernel using a dedicated hypercall. This is necessary > > for e.g. virtio communications, so these shared pages need to be mapped > > back into the VMM's address space. I'm a bit confused about how that > > would work with the approach proposed here. What is going to be the > > approach for TDX? > > > > It feels like the most 'natural' thing would be to have a KVM exit > > reason describing which pages have been shared back by the guest, and to > > then allow the VMM to mmap those specific pages in response in the > > memfd. Is this something that has been discussed or considered? > > The proposed solution is to exit to userspace with a new exit reason, KVM_EXIT_MEMORY_ERROR, > when the guest makes the hypercall to request conversion[1]. The private fd itself > will never allow mapping memory into userspace, instead userspace will need to punch > a hole in the private fd backing store. The absense of a valid mapping in the private > fd is how KVM detects that a pfn is "shared" (memslots without a private fd are always > shared)[2]. Right. I'm still a bit confused about how the VMM is going to get the shared page mapped in its page-table. Once it has punched a hole into the private fd, how is it supposed to access the actual physical page that the guest shared? Is there an assumption somewhere that the VMM should have this page mapped in via an alias that it can legally access only once it has punched a hole at the corresponding offset in the private fd or something along those lines? > 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? What happens if it does so for a page that a guest hasn't shared back? > Another important detail is that this approach means the kernel and KVM treat the > shared backing store and private backing store as independent, albeit related, > entities. This is very deliberate as it makes it easier to reason about what is > and isn't allowed/required. E.g. the kernel only needs to handle freeing private > memory, there is no special handling for conversion to shared because no such path > exists as far as host pfns are concerned. And userspace doesn't need any new "rules" > for protecting itself against a malicious guest, e.g. userspace already needs to > ensure that it has a valid mapping prior to accessing guest memory (or be able to > handle any resulting signals). A malicious guest can DoS itself by instructing > userspace to communicate over memory that is currently mapped private, but there > are no new novel attack vectors from the host's perspective as coercing the host > into accessing an invalid mapping after shared=>private conversion is just a variant > of a use-after-free. Interesting. I was (maybe incorrectly) assuming that it would be difficult to handle illegal host accesses w/ TDX. IOW, this would essentially crash the host. Is this remotely correct or did I get that wrong? > One potential conversions that's TBD (at least, I think it is, I haven't read through > this most recent version) is how to support populating guest private memory with > non-zero data, e.g. to allow in-place conversion of the initial guest firmware instead > of having to an extra memcpy(). Right. FWIW, in the pKVM case we should be pretty immune to this I think. The initial firmware is loaded in guest memory by the hypervisor itself (the EL2 code in arm64 speak) as the first vCPU starts running. And that firmware can then use e.g. virtio to load the guest payload and measure/check it. IOW, we currently don't have expectations regarding the initial state of guest memory, but it might be handy to have support for pre-loading the payload in the future (should save a copy as you said). > [1] KVM will also exit to userspace with the same info on "implicit" conversions, > i.e. if the guest accesses the "wrong" GPA. Neither SEV-SNP nor TDX mandate > explicit conversions in their guest<->host ABIs, so KVM has to support implicit > conversions :-/ > > [2] Ideally (IMO), KVM would require userspace to completely remove the private memslot, > but that's too slow due to use of SRCU in both KVM and userspace (QEMU at least uses > SRCU for memslot changes).