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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 738D5C4320A for ; Wed, 1 Sep 2021 18:24:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EFE2C6109E for ; Wed, 1 Sep 2021 18:24:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EFE2C6109E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 38ACE8D0002; Wed, 1 Sep 2021 14:24:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33BA48D0001; Wed, 1 Sep 2021 14:24:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DB178D0002; Wed, 1 Sep 2021 14:24:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0185.hostedemail.com [216.40.44.185]) by kanga.kvack.org (Postfix) with ESMTP id 0E8CC8D0001 for ; Wed, 1 Sep 2021 14:24:36 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id DBF8013089 for ; Wed, 1 Sep 2021 18:24:34 +0000 (UTC) X-FDA: 78539830068.26.7B24155 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf26.hostedemail.com (Postfix) with ESMTP id 7AEF520019EC for ; Wed, 1 Sep 2021 18:24:34 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 74BDE60724; Wed, 1 Sep 2021 18:24:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1630520673; bh=oG3UR1b0S7YAGQmjwOu2Zyz76lEjCq5yTG2uKcqa9KA=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=D2NMnlXUrEvbrtKVjx1kK9teKjOL1MmzspE9zIhUB8I8pr/QmwdCdlzB3fJZ3NJaq BmOfYD5GBZ7WSGE15fcR3lX01UAuobSCBdrlakocz/KcZanPAMfyx5Qp7UFP9DK/+V aGq7TyTodjIk2sWMi6vqmH9sk08ZS8ZtMkXwv+CHWDVoW5exGjNiK2Bx5YbHMq/W5n RSDQPpW5lt4Xq9rm7ZOXsW9rSpqUkl6AmB728IRzWOawBDrlpiQreMOE7CXJvimEeO SrMFLJw7jARcFVct7ccZxZ/2EwrcXuOIJeQLJK5K3h1i39K8Bud8I1V9nrCeioL0zA 1K99rX12e06KA== Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 96A2427C0054; Wed, 1 Sep 2021 14:24:30 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Wed, 01 Sep 2021 14:24:30 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddvfedguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnhepgeejgffhtdelvdefgeefleevtdfgveekuefgkeffvdevfeefteei heeuteevkeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudek heeifedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuh igrdhluhhtohdruhhs X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DB913A002E4; Wed, 1 Sep 2021 14:24:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1126-g6962059b07-fm-20210901.001-g6962059b Mime-Version: 1.0 Message-Id: <40115c03-255b-4328-b0a2-fb60d707c4a2@www.fastmail.com> In-Reply-To: References: <20210824005248.200037-1-seanjc@google.com> <307d385a-a263-276f-28eb-4bc8dd287e32@redhat.com> <61ea53ce-2ba7-70cc-950d-ca128bcb29c5@redhat.com> <9ec3636a-6434-4c98-9d8d-addc82858c41@www.fastmail.com> Date: Wed, 01 Sep 2021 11:24:04 -0700 From: "Andy Lutomirski" To: "James Bottomley" , "David Hildenbrand" , "Sean Christopherson" Cc: "Paolo Bonzini" , "Vitaly Kuznetsov" , "Wanpeng Li" , "Jim Mattson" , "Joerg Roedel" , "kvm list" , "Linux Kernel Mailing List" , "Borislav Petkov" , "Andrew Morton" , "Joerg Roedel" , "Andi Kleen" , "David Rientjes" , "Vlastimil Babka" , "Tom Lendacky" , "Thomas Gleixner" , "Peter Zijlstra (Intel)" , "Ingo Molnar" , "Varad Gautam" , "Dario Faggioli" , "the arch/x86 maintainers" , linux-mm@kvack.org, linux-coco@lists.linux.dev, "Kirill A. Shutemov" , "Kirill A . Shutemov" , "Sathyanarayanan Kuppuswamy" , "Dave Hansen" , "Yu Zhang" Subject: =?UTF-8?Q?Re:_[RFC]_KVM:_mm:_fd-based_approach_for_supporting_KVM_guest_?= =?UTF-8?Q?private_memory?= Content-Type: text/plain Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=D2NMnlXU; spf=pass (imf26.hostedemail.com: domain of luto@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 7AEF520019EC X-Stat-Signature: er9whswk8ji5wtwurrfbnturmqffr616 X-HE-Tag: 1630520674-465916 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, Sep 1, 2021, at 9:18 AM, James Bottomley wrote: > On Wed, 2021-09-01 at 08:54 -0700, Andy Lutomirski wrote: > [...] > > If you want to swap a page on TDX, you can't. Sorry, go directly to > > jail, do not collect $200. > > Actually, even on SEV-ES you can't either. You can read the encrypted > page and write it out if you want, but unless you swap it back to the > exact same physical memory location, the encryption key won't work. > Since we don't guarantee this for swap, I think swap won't actually > work for any confidential computing environment. > > > So I think there are literally zero code paths that currently call > > try_to_unmap() that will actually work like that on TDX. If we run > > out of memory on a TDX host, we can kill the guest completely and > > reclaim all of its memory (which probably also involves killing QEMU > > or whatever other user program is in charge), but that's really our > > only option. > > I think our only option for swap is guest co-operation. We're going to > have to inflate a balloon or something in the guest and have the guest > driver do some type of bounce of the page, where it becomes an > unencrypted page in the guest (so the host can read it without the > physical address keying of the encryption getting in the way) but > actually encrypted with a swap transfer key known only to the guest. I > assume we can use the page acceptance infrastructure currently being > discussed elsewhere to do swap back in as well ... the host provides > the guest with the encrypted swap page and the guest has to decrypt it > and place it in encrypted guest memory. I think the TD module could, without hardware changes, fairly efficiently re-encrypt guest pages for swap. The TD module has access to the full CPU crypto capabilities, so this wouldn't be slow. It would just require convincing the TD module team to implement such a feature. It would be very, very nice for whatever swap support ends up existing to work without guest cooperation -- even if the guest is cooperative, we don't want to end up waiting for the guest to help when the host is under memory pressure.