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 4BF30C48297 for ; Wed, 7 Feb 2024 02:43:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BDAEA6B007D; Tue, 6 Feb 2024 21:43:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B8AB66B007E; Tue, 6 Feb 2024 21:43:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A52546B0080; Tue, 6 Feb 2024 21:43:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9340C6B007D for ; Tue, 6 Feb 2024 21:43:43 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AA339A2021 for ; Wed, 7 Feb 2024 02:43:42 +0000 (UTC) X-FDA: 81763462284.03.BA973D1 Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) by imf01.hostedemail.com (Postfix) with ESMTP id E68274000E for ; Wed, 7 Feb 2024 02:43:40 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4xgbhz7P; spf=pass (imf01.hostedemail.com: domain of 3XO7CZQYKCHkpbXkgZdlldib.Zljifkru-jjhsXZh.lod@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3XO7CZQYKCHkpbXkgZdlldib.Zljifkru-jjhsXZh.lod@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707273821; a=rsa-sha256; cv=none; b=PFCmlJemnxTwhGsUwh6dP3WhTaloJ1n1q/fdvYlMhdbx/ksHHvHjNo8RteSswdEZNXMRaf 2wxmTe/e7gyJO85k7xA2kjEW6yfMroX5QADUkvR924iqLM5Lmwyhvl3n7IFmMyy1WjxlcD 6Hc5P7Lvp0QWmtsaWBvLYip7dHiNXUo= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4xgbhz7P; spf=pass (imf01.hostedemail.com: domain of 3XO7CZQYKCHkpbXkgZdlldib.Zljifkru-jjhsXZh.lod@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3XO7CZQYKCHkpbXkgZdlldib.Zljifkru-jjhsXZh.lod@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707273821; 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=g7guOO3K6cZeccVPYodTSSR3CLbTuFzc0JepOhwBqf8=; b=6rgWjBAYrQtgPUkBSOB9PZqyKFUaPHgF+5zG1z47cPRVJ4oMJAAN+9Z49iJ1Y2K99whb4e 5+o5UVs49TvRIbw8IZCiA+7f3dYz3ImVuy9joWsJTOUcNIVVda09IBubkWCGWXAXO6jOAT McOra1wqSLeWVueFQuiWpMV5E9tZl6M= Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-dc6ceade361so256906276.0 for ; Tue, 06 Feb 2024 18:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707273820; x=1707878620; darn=kvack.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=g7guOO3K6cZeccVPYodTSSR3CLbTuFzc0JepOhwBqf8=; b=4xgbhz7PCFeT6Ea83cgqUEjF/j2GsULVnL/shnO384TZ0Ge4tPZsUB3g+GA6s5XvZp T9etC+qRSw+vujXQMf5Xt97zwETq5xHGA7nwpoFYmvlbqYA3OoeRaQwa0XAwKIN0d2bo DDnznP/QrLz25z/I1A8zD/gAb5HJCz5YB4hLXpHHOMkZrtlU4jz10J19cmlpVApe1Amo wEOnyjg4L/DOvIaxhBWUO/c3SHAROodWUsAje4ahR8kj/daB0S6AhukzYQFGoq8yO62R NFnPOqGogWsiKLpMLCCmbpK1CrA4k/BtW4/wnoZCpDgMZZZP1Hh4w0+Hhe819wQp2WG0 WfXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707273820; x=1707878620; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=g7guOO3K6cZeccVPYodTSSR3CLbTuFzc0JepOhwBqf8=; b=mlBGoSDeGe30bvqA1/uVsCT6oBAr7wOoUdQs4HCgtNznlP60IQsb/xY1w9tbeIZxzg w4AUBEvqOE80c4yTjE1WGw1VUb0BoLYGhhfR2PSGqAZztUlsakhSYpwByk+rrwQ4L34L 1hRC9HxDbt38+o1T/fkg4GO1WLYaDYgMeus94WHb5/Gy8HUII0pYy1AIGJZFd8psP42Z jFtWIL843d9YL2aGsvTwyvHzNkeXYsAETWZ4GV2AH8BCBpm5eo76l+D2BHMqqvnThwDU 5alWYWg5vSZ+TEWXyQsOF7SXmvwDLoWzeXzGMO4BpRr8azC3veYsSLQ5eoFGhI53XSSl WpRA== X-Gm-Message-State: AOJu0Yweskq7BxZ858l8fZ0dUpQ3UTN0eMMlrczEdo+YUFCEeSE2o0DI iWcAv1kmDfiQzkYVEg30jer9vEZc0DkHfNCbS5jZvXNc8zjDFFkhyYwSn6Ea42mLff65n6zOJfs vHA== X-Google-Smtp-Source: AGHT+IHFKn95FP8tDKGyeHSLkuyZnMtdrnlqEFcDN45UncE4QphOeyXOIkcKI10ZFatjnFxEnz3hwTc5JAw= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:2485:b0:dc2:550b:a4f4 with SMTP id ds5-20020a056902248500b00dc2550ba4f4mr906756ybb.1.1707273820039; Tue, 06 Feb 2024 18:43:40 -0800 (PST) Date: Tue, 6 Feb 2024 18:43:38 -0800 In-Reply-To: Mime-Version: 1.0 References: <20231230172351.574091-1-michael.roth@amd.com> <20231230172351.574091-19-michael.roth@amd.com> <20240116041457.wver7acnwthjaflr@amd.com> Message-ID: Subject: Re: [PATCH v11 18/35] KVM: SEV: Add KVM_SEV_SNP_LAUNCH_UPDATE command From: Sean Christopherson To: Paolo Bonzini 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: E68274000E X-Stat-Signature: iwod45na1hiqdso35jigc337p8jy3dgj X-Rspam-User: X-HE-Tag: 1707273820-505129 X-HE-Meta: U2FsdGVkX18N2MkY9NnZy44OPdjGX85dwC+9vcndi9r0+Jz64sdzu7heGDjqHWHS8Nh5aDrW326U4vk45yNs/31KhBgtpKjWrEyyIsvDrOCsJ4UxuiYupXHHkHzijif1hujI5AycflNK2Qb/JJ4IZnmHIMDs6QDGMJV1cqugTeMweKmbTd9Gx6kIhB5tc+uD5swVNFbU45PTtN52Qe9fmvPu2cS/N99DeJPyDua8+QC/zZDI3G08TVYh8Z1Va8DMRawLv13nfNEQ1E8B+oHEGeQK7u6Dzfpc/0muswq7K3FQl6q+XtMsD8j4eZYFRXicRvXYoyZVeOfbwdCfMUrecSIyISgVqQNqJMQ2IvMkQbNesMQFw+duH1GWYgykPFVYZmgFbEd+JSMJatbIIWH8srTh1JyEaMc8PtLZ/D/xv87T57jnMc3BM2/nD2EqFTcXdy3Kd+4EcHi6IDbqExONs+SElPVitS6Ov4gLrgcMo2+RFp/xh32AOMYSlkVPRwAiwo35bDXrOid2A6naGcmiBV7E24WHSZBHI2MB1FV+RqOPY5qe3UTt56n3cg0STm63LMGHXaaF3RsHgYPbdofDHAfx2VQi1VQ6CJpPJ30IUoUxL5lgWNsiJOeEFV1KkSNKSM+du3aDGkWaxtRjguwdp6Emoz0QDdcnIlGfMLZL0/1qT6KVO5RWPlYMhdwOspR91sve+NzrohPsDDPCyyMZv9RryVNWObvb23bhTkyCi42U59sKiAoG1JH2yU/22WsMtTTAUkYMlgmnLOYxlEu/PF+ydNV0MRTCC6GKLYffp+ff748oCIkqEy2MWewhFvVXyyFYHrmzAnhwoyiSLNevhq0OHWxaISU/6BvUlk+sJiaiOzH4qAgJkoLRfHhQyKxNpfrFZJ+5I5q4tZ4uxxw1PZGzZ4yE6opW/t5jyZoH/YP4+hGVQajGqHWneSzf+1NLc1AIYiJS6rE5ZzCbXsL IsDyeJBC oEDy8Xipq8tCzb4iaZGGD1Iko+Z8q0gdJ6vDIZ/vkxVLtK9d2I+Fl5nJfgZX64KA/vaoir6GLWbRQUV0vZu11QuzSyQw1TzbF0t8WiDVWPlnQPcWTWLefLpVZihVvSxAbafv5wY25pQ5c3eeG9OJgplWtAlEHtHs/4/GIBnfqFv0XP4sx9eVCs+HQl/H8UFwMbi+9/LuVPeB7KIN4LVlL8SdScxVC7IDPN0LqLgqX2vd1LVRDuns71oKwfZcQSHBt36aEyAq4D3rPYFblg4zXKereRi/VkDCKO552TLqAQ5HVrrYE3TSxDvjm1zyiYM1uZfusNdiTFFoqriDvR/6uBCbipJq4RvrNyfZWhlRUzXMDStoNPPMk+OWVl2oOBPIkUcNEJHRBkrwfs0ChL3zS4kdLObbAtyvVXDDLI9SJx/w+hcNNOCWKfSI62XM+VyazquoxPpflSdfMI0yU1oPqbW+kyy/sq0Kxvlq1ae68/yfPu0AoyL9k48tudqylG0X0SVnVvetLONamyxCmFxprg0hfS21NKdZYMhv36RiBH7kMrerj6+pgQyI4JQkSPPDk9lMn1rvl3nDM7z4S23jWFAis4vkEFAKBYTJdkL/saScjQuuUmgSOfJn7AcpM7ui/hZ1ezdUIH1yryWQRq/41SIvnAw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000414, 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 07, 2024, Paolo Bonzini wrote: > On Fri, Feb 2, 2024 at 11:55=E2=80=AFPM Sean Christopherson wrote: > > > It doesn't really matter if the attributes are set before or after > > > KVM_SNP_LAUNCH_UPDATE, only that by the time the guest actually launc= hes > > > they pages get set to private so they get faulted in from gmem. We co= uld > > > document our expectations and enforce them here if that's preferable > > > however. Maybe requiring KVM_SET_MEMORY_ATTRIBUTES(private) in advanc= e > > > would make it easier to enforce that userspace does the right thing. > > > I'll see how that looks if there are no objections. > > > > Userspace owns whether a page is PRIVATE or SHARED, full stop. If KVM = can't > > honor that, then we need to come up with better uAPI. >=20 > Can you explain more verbosely what you mean? As proposed, snp_launch_update_gfn_handler() doesn't verify the state of th= e gfns' attributes. But that's a minor problem and probably not a sticking p= oint. My overarching complaint is that the code is to be wildly unsafe, or at the= very least brittle. Without guest_memfd's knowledge, and without holding any lo= cks beyond kvm->lock, it=20 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 that'= s before KVM gains support for intrahost migration, i.e. before KVM allows mu= ltiple VM instances to bind to a single guest_memfd. But I _think_ we mostly sorted this out at PUCK. IIRC, the plan is to have= guest_memfd provide (kernel) APIs to allow arch/vendor code to initialize a guest_memfd= range. That will give guest_memfd complete control over the state of a given page,= will allow guest_memfd to take the appropriate locks, and if we're lucky, will b= e reusable by other CoCo flavors beyond SNP. > > > > > + * When invalid CPUID function entries are dete= cted, the firmware > > > > > + * corrects these entries for debugging purpose= and leaves the > > > > > + * page unencrypted so it can be provided users= for debugging > > > > > + * and error-reporting. > > > > > > > > Why? IIUC, this is basically backdooring reads/writes into guest_m= emfd to avoid > > > > having to add proper mmap() support. > > > > Yes, I am specifically complaining about writing guest memory on failur= e, which is > > all kinds of weird. >=20 > 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, kvad= dr, 0, PAGE_SIZE); + if (ret) + pr_err("Failed to write CPUID page = back to userspace, ret: 0x%x\n", + ret); I have no objection to propagating error/debug information back to userspac= e, but it needs to be routed through the source page (or I suppose some dedica= ted error page, but that seems like overkill). Shoving the error information i= nto guest memory is gross. But this should naturally go away when the requirement that the source be covered by the same memslot also goes away.