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=-13.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 B8243C4743C for ; Fri, 4 Jun 2021 17:41:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3B9A4610C7 for ; Fri, 4 Jun 2021 17:41:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B9A4610C7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 994446B006E; Fri, 4 Jun 2021 13:41:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9444F6B0070; Fri, 4 Jun 2021 13:41:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7BDF16B0071; Fri, 4 Jun 2021 13:41:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0221.hostedemail.com [216.40.44.221]) by kanga.kvack.org (Postfix) with ESMTP id 465446B006E for ; Fri, 4 Jun 2021 13:41:57 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C8E9110FE3 for ; Fri, 4 Jun 2021 17:41:56 +0000 (UTC) X-FDA: 78216759432.19.C5284D1 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf18.hostedemail.com (Postfix) with ESMTP id 23A5320015C8 for ; Fri, 4 Jun 2021 17:41:41 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id A7D0F613F9; Fri, 4 Jun 2021 17:16:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622827010; bh=xwMM+2G/mmCpLqX14QgttleAlbZ6mPunUvzw1rIgCFY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=bARl4IhZVIFB42SHv69WoBjsmdnDpkVNDrAOuTC72KTseADE8m0I8viIsrFpkJqFH eu55Lww2tBSmnjWAwa8ZQ+qj981URrrG6A1NrLW4mIPRtFeDOP2tiIKNTH4WkU4/iR 6FerihuNYfudlF66fz/QJDI8jezs1roZ1gHPyi69QZFfikyFYIyVGwFnZvnbJSwXrX zzpbL6b644Dl7gtMAeFSSL7Xl7Z5dO8Q5YHlM7V/n9El8e+ckckVqELGhB2HX2/KLY I8TBeX0VEaq/hy5ZTfnNlP1Bcl2Z9bhaYhTN+5RYdszw2qaWRPvB++gDDksbb8d6X7 4NYltEWJ7mvcQ== Subject: Re: [RFCv2 13/13] KVM: unmap guest memory using poisoned pages To: "Kirill A. Shutemov" , Sean Christopherson Cc: "Kirill A. Shutemov" , Dave Hansen , Peter Zijlstra , Jim Mattson , David Rientjes , "Edgecombe, Rick P" , "Kleen, Andi" , "Yamahata, Isaku" , Erdem Aktas , Steve Rutherford , Peter Gonda , David Hildenbrand , Chao Peng , x86@kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20210416154106.23721-14-kirill.shutemov@linux.intel.com> <20210419142602.khjbzktk5tk5l6lk@box.shutemov.name> <20210419164027.dqiptkebhdt5cfmy@box.shutemov.name> <20210419185354.v3rgandtrel7bzjj@box> <20210419225755.nsrtjfvfcqscyb6m@box.shutemov.name> <20210521123148.a3t4uh4iezm6ax47@box> From: Andy Lutomirski Message-ID: Date: Fri, 4 Jun 2021 10:16:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20210521123148.a3t4uh4iezm6ax47@box> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Stat-Signature: zeowj4w9eq5n3xqb8dumy8eypj55uj4d X-Rspamd-Queue-Id: 23A5320015C8 X-Rspamd-Server: rspam02 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bARl4IhZ; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of luto@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=luto@kernel.org X-HE-Tag: 1622828500-717099 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 5/21/21 5:31 AM, Kirill A. Shutemov wrote: > Hi Sean, > > The core patch of the approach we've discussed before is below. It > introduce a new page type with the required semantics. > > The full patchset can be found here: > > git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git kvm-unmapped-guest-only > > but only the patch below is relevant for TDX. QEMU patch is attached. > > CONFIG_HAVE_KVM_PROTECTED_MEMORY has to be changed to what is appropriate > for TDX and FOLL_GUEST has to be used in hva_to_pfn_slow() when running > TDX guest. > > When page get inserted into private sept we must make sure it is > PageGuest() or SIGBUS otherwise. Inserting PageGuest() into shared is > fine, but the page will not be accessible from userspace. I may have missed a detail, and I think Sean almost said this, but: I don't think that a single bit like this is sufficient. A KVM host can contain more than one TDX guest, and, to reliably avoid machine checks, I think we need to make sure that secure pages are only ever mapped into the guest to which they belong, as well as to the right GPA. If a KVM user host process creates a PageGuest page, what stops it from being mapped into two different guests? The refcount? After contemplating this a bit, I have a somewhat different suggestion, at least for TDX. In TDX, a guest logically has two entirely separate physical address spaces: the secure address space and the shared address space. They are managed separately, they have different contents, etc. Normally one would expect a given numerical address (with the secure selector bit masked off) to only exist in one of the two spaces, but nothing in the architecture fundamentally requires this. And switching a page between the secure and shared states is a heavyweight operation. So what if KVM actually treated them completely separately? The secure address space doesn't have any of the complex properties that the shared address space has. There are no paravirt pages there, no KSM pages there, no forked pages there, no MAP_ANONYMOUS pages there, no MMIO pages there, etc. There could be a KVM API to allocate and deallocate a secure page, and that would be it. This could be inefficient if a guest does a bunch of MapGPA calls and makes the shared address space highly sparse. That could potentially be mitigated by allowing a (shared) user memory region to come with a bitmap of which pages are actually mapped. Pages in the unmapped areas are holes, and KVM won't look through to the QEMU page tables. Does this make any sense? It would completely eliminate all this PageGuest stuff -- a secure page would be backed by a *kernel* allocation (potentially a pageable allocation a la tmpfs if TDX ever learns how to swap, but that's no currently possible nor would it be user visible), so the kernel can straightforwardly guarantee that user pagetables will not contain references to secure pages and that GUP will not be called on them. I'm not sure how this would map to SEV. Certainly, with some degree of host vs guest cooperation, SEV could work the same way, and the migration support is pushing SEV in that direction.