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 E9D2DC4828F for ; Wed, 7 Feb 2024 08:03:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D1326B0074; Wed, 7 Feb 2024 03:03:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4810F6B0075; Wed, 7 Feb 2024 03:03:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 321A16B0078; Wed, 7 Feb 2024 03:03:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 240FF6B0074 for ; Wed, 7 Feb 2024 03:03:31 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BD75BC0917 for ; Wed, 7 Feb 2024 08:03:30 +0000 (UTC) X-FDA: 81764268180.27.CEDC76D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf09.hostedemail.com (Postfix) with ESMTP id 90536140030 for ; Wed, 7 Feb 2024 08:03:28 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Gchjrn6A; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf09.hostedemail.com: domain of pbonzini@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=pbonzini@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707293008; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=P2cTjV2SgwNJoZVYjRYppg2qiwtD1i4vzmwnoPMVa3o=; b=a9QhRJYPTxkgvhPAF3jevHgULrUHhqRZQQiBrcaM9vJ84TRIjzjp7GMp7tPiKjyIN0/Y/B ZZmrwEWxw5vPeBl2+0SdPHspma2wuPRyu0pFBgtfqnrP+PlUloa/sBdeNVdXBCwPNBSYMu LvF1c1Cc+PamTCU6EQK/R9Dl4k5i21Q= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Gchjrn6A; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf09.hostedemail.com: domain of pbonzini@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=pbonzini@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707293008; a=rsa-sha256; cv=none; b=0b5+uRgKxNhObiHVAzPFIqkUexu+24Uv6zHsnPj1/6lX94YZVJ2yqBYomHK6f/pXjyO0Fo 6pibLG8f1WJRFrtyepCCdN04kuSgwPpxIgjaeXsKJOm2RHQHfBnwNVab5irOnWY+j7qP3E g1IyT5fHfEgY87gB4KsSj1bSuAdH82U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707293007; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=P2cTjV2SgwNJoZVYjRYppg2qiwtD1i4vzmwnoPMVa3o=; b=Gchjrn6AWMGCpTN4f9vIcpPWWPc4xfHbkXyImCqNBT7hrjhhTPfY49vY8q/hvQQPGdtgev 3UkrAX2jnGVNJOCPhHgmmcpW2E9hkdQrpCBZ5rMt7W+RgocVla/V/LXMUcct/GicOYQh4O R9nUxksrM5LgsSE6r6s5vZR/Fl2CWT0= Received: from mail-vs1-f72.google.com (mail-vs1-f72.google.com [209.85.217.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-6-B8psjytEOiOPduKVOqBDxA-1; Wed, 07 Feb 2024 03:03:26 -0500 X-MC-Unique: B8psjytEOiOPduKVOqBDxA-1 Received: by mail-vs1-f72.google.com with SMTP id ada2fe7eead31-46d319fd52aso397082137.1 for ; Wed, 07 Feb 2024 00:03:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707293006; x=1707897806; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=P2cTjV2SgwNJoZVYjRYppg2qiwtD1i4vzmwnoPMVa3o=; b=faKut9k+emtS0m3lCZIIQfaiqqwBH7dAnWmXsIxeh/ZyYRDxsjM+QKOXQe+FrIj+Tc 6M2BTv77bvtnzkSLpbhRDAu0fUdDcnynxOTAkSLbqVHBa4S2nMuBOC4C+tAQZ7wPxqna I+wMIYxZKvceOPel37sxhoSMiriJVcVicC3BK/DonUrGe5+i6OXgnae0AzoXYhHR8Epm G5d4XdFq2kNDm8YkmxPnRb0n1bPG3cURgtPSpN4h0JCkLBsX0LkWPjhe9m9/LQYxf0Ag ly5erwcgONqy8flxZacMUHmy7uv9x9CsBeOqzIeGw5jvDu+JKGu/PNSfmY3eBbyrhhIH 7tkQ== X-Gm-Message-State: AOJu0Yw4bMV3HESefy5NvP5SEb0GSsWMcr/nq7sNKsohwr1TKSlaC+9v SLM0ctwWCraz5/WD6JSAwob7VHfGX87M/2V1I+lj6JjJUK9l/uTP0/skbJirCZ5pkrJtuG0NIg8 OwDEL7+8uOSJOgM98MfE8ek0dd//zverbiotmBPP2NLXQC70Voee6ZJVtGAYkZRlqE9PCfSkL1f F5d+0TE1duvLPX+4HTBvDx4Jg= X-Received: by 2002:a05:6102:2362:b0:46d:2b0f:aeb5 with SMTP id o2-20020a056102236200b0046d2b0faeb5mr1289264vsa.16.1707293006031; Wed, 07 Feb 2024 00:03:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IEaZzeu/zdF20sLH9pOgZUQvjc4KHv6RddT40BWYC2FIjhnKgF5FPo4oS7Mufd54mwaj/3nM5NsQwxICjqiu1o= X-Received: by 2002:a05:6102:2362:b0:46d:2b0f:aeb5 with SMTP id o2-20020a056102236200b0046d2b0faeb5mr1289258vsa.16.1707293005763; Wed, 07 Feb 2024 00:03:25 -0800 (PST) MIME-Version: 1.0 References: <20231230172351.574091-1-michael.roth@amd.com> <20231230172351.574091-19-michael.roth@amd.com> <20240116041457.wver7acnwthjaflr@amd.com> In-Reply-To: From: Paolo Bonzini Date: Wed, 7 Feb 2024 09:03:13 +0100 Message-ID: Subject: Re: [PATCH v11 18/35] KVM: SEV: Add KVM_SEV_SNP_LAUNCH_UPDATE command To: Sean Christopherson Cc: Michael Roth , kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, vkuznets@redhat.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, bp@alien8.de, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com, pankaj.gupta@amd.com, liam.merwick@oracle.com, zhi.a.wang@intel.com, Brijesh Singh X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: kxf8a871rq468yibqp5o59c9y75uafci X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 90536140030 X-HE-Tag: 1707293008-700232 X-HE-Meta: U2FsdGVkX1/voGrJq09nN9x4FRN6RGtX2yyAs94p6aGrd9RdLgI/kKKGElMbQvzxM7XUU1gaGPViYs3ttRGLTWyU7G4dicytMIH6Vxc1DjB6I4u62dqJhFAmVyAaam+SaTYBsycsXsAAP8Hcgt7Yv4cmYQzzn6KD+KkgyF/gjOlWUsNIzC6RKfiWqKxYkaGAML2gMtOIrjJ8vvR7Alx32+pB5EzciLM1x570eaW2iI7Ibs0RDBXq3QIESZj639P99Z0s6qHBUNpGkxcebFiqLg315bnKDIFFeSpX9PIhFU/sCCsBxJuh7Upj0kB97lyMbqS2ohWOXKSuPfM9bspsOM/8/W4Ker9yu3ZEpvFhb0CzjN0iTUU5oMWNXcAag+6JZuPvB8TKx5I7OMazv7s/88GkeRADioVYKHI81VWC85M+6fjHEbWNyPH0flTCCuN31ZD9feVEF6gfCZiZKjCmtS5iYLUtgLj4aRy8cQbh0eimj+SmfgqF2NVn4zRIlEcFFc/jSIwMQuMAr79Yt7QwTHQ2/PRGyv0d7ZpoZdEwrDhkr1fOapYUAzqrN0VkAacRKn2HDTept98j9UUAw5X6LKF5NRCW1atyBiZIwq3CuxUqLdObv5hFP63vTThqHpBzmkcL35d8x5O9u9pSRyDk529GxWpu2qu6Uzd34UCHuzwIw3SI8FK+gFokGba3yTUPbJtRRiQxjtUGPxafAb8JS3MMQsa2gU9TeqIa+UIsBEdbd6/EaQtRPLKJJVe5JZFSUGe3Lv17go5dGN08RLUbkBJJkH6fqTAmIr0rfiGbK1meFqa+OktyZ3r9tJxPinObyK2fUrtd/49it6V5m9TsTbhgbVrC5zL9/QULUO5VYkH/bwoZIT8vEBBrpn8QtSJ9ewNJNAxrTts0BKcOjEs7Y9TQOkvI5v7q/fmCpN54J0qXD/QZ+XZ6oUlwef0vg2PIYaTsjJc+39f/tWaI618 qp6OHMmI vtRegZGBKFGoQhzI9NSFdXlNrJRIndaNFBZq1oKy+A2TFYFp29of7gD8pJKioCrlli2RMXnjp0CsVCKJhkpNeq9tNF7BRrcG1K/iqBLcA3ShiKXRR2Dd0jYoaKwEuYdneXGhF8stp5JzvQIVOCz9aLKLmvv54Jnh4xJZLtsDWcwZbVl9f98SarYjkveLMn894imGKH/s/6+MTKul+cTxZjJmFDvwQyZOOx72oh+jVvSOnVVMWUc07Zg1ov67bMwH0cjPK9SBV561h46vedzvcqqVXQ3WSjgZdocrRjk5+hSynAIFbjcjpkIU2Ug== 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: List-Subscribe: List-Unsubscribe: On Wed, Feb 7, 2024 at 3:43=E2=80=AFAM Sean Christopherson wrote: > > > Userspace owns whether a page is PRIVATE or SHARED, full stop. If KV= M can't > > > honor that, then we need to come up with better uAPI. > > > > Can you explain more verbosely what you mean? > > As proposed, snp_launch_update_gfn_handler() doesn't verify the state of = the > gfns' attributes. But that's a minor problem and probably not a sticking= point. > > My overarching complaint is that the code is to be wildly unsafe, or at t= he very > least brittle. Without guest_memfd's knowledge, and without holding any = locks > beyond kvm->lock, it > > 1) checks if a pfn is shared in the RMP > 2) copies data to the page > 3) converts the page to private in the RMP > 4) does PSP stuff > 5) on failure, converts the page back to shared in RMP > 6) conditionally on failure, writes to the page via a gfn > > I'm not at all confident that 1-4 isn't riddled with TOCTOU bugs, and tha= t's > before KVM gains support for intrahost migration, i.e. before KVM allows = multiple > VM instances to bind to a single guest_memfd. Absolutely. > But I _think_ we mostly sorted this out at PUCK. IIRC, the plan is to ha= ve guest_memfd > provide (kernel) APIs to allow arch/vendor code to initialize a guest_mem= fd range. > That will give guest_memfd complete control over the state of a given pag= e, will > allow guest_memfd to take the appropriate locks, and if we're lucky, will= be reusable > by other CoCo flavors beyond SNP. Ok, either way it's clear that guest_memfd needs to be in charge. Whether it's MEMORY_ENCRYPT_OP that calls into guest_memfd or vice versa, that only matters so much. > > > Yes, I am specifically complaining about writing guest memory on fail= ure, which is > > > all kinds of weird. > > > > It is weird but I am not sure if you are complaining about firmware > > behavior or something else. > > This proposed KVM code: > > + host_rmp_make_shared(pfns[i], PG_LEVEL_4K= , true); > + > + ret =3D kvm_write_guest_page(kvm, gfn, kv= addr, 0, PAGE_SIZE); > + if (ret) > + pr_err("Failed to write CPUID pag= e back to userspace, ret: 0x%x\n", > + ret); > > > I have no objection to propagating error/debug information back to usersp= ace, > but it needs to be routed through the source page (or I suppose some dedi= cated > error page, but that seems like overkill). Shoving the error information= into > guest memory is gross. Yes, but it should be just a consequence of not actually using start_gfn. Having to copy back remains weird, but what can you do. Paolo