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 D6B09C48297 for ; Tue, 6 Feb 2024 23:43:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1E64B6B0072; Tue, 6 Feb 2024 18:43:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1967F6B0075; Tue, 6 Feb 2024 18:43:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 036336B007D; Tue, 6 Feb 2024 18:43:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E75FE6B0072 for ; Tue, 6 Feb 2024 18:43:19 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id AED82160412 for ; Tue, 6 Feb 2024 23:43:19 +0000 (UTC) X-FDA: 81763007718.08.70154D0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf26.hostedemail.com (Postfix) with ESMTP id 9B1AB140002 for ; Tue, 6 Feb 2024 23:43:17 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AOQvmWLa; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf26.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=1707262997; a=rsa-sha256; cv=none; b=KnhoXVjtLsRbbyM2w5GVG+LovfhfQNDVBrUWG+JZHL60DW5Er7ZwakXPn1691P9d1MiUDM NrVd91MAfp7rioTI3gygjFT6CVTuF+mHuD1zwqd8r3HL7GD5tpEo9mbOQzaqkxg7ywUv6T hK2rEDCm+E5NierKRqpbbt4lvuru/Ck= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AOQvmWLa; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf26.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=1707262997; 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=BKqi7t1q2HxhNGO8YhAm57zpm7GYMl8tE7F26XImgsE=; b=WzDEcnad3nXx8Ii+spb8+CwK0tsphkxcnq0m80rh4NLVbd/AdNfgWBoRgQSb9UwnxynzIW DuCdGzBu2IjuhToC/sdyNBnG5uE3OOVtvu6AIYYMJrSVYQFFfYKA30/HBrFb0oDPubSJU2 PLqZkEqng5vUO6VwhwjPzzOUysUnBvI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707262997; 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=BKqi7t1q2HxhNGO8YhAm57zpm7GYMl8tE7F26XImgsE=; b=AOQvmWLasmf/9ebnCzMWgtIRlhthrcoYDPB3ODRGMOEsvTbMCZbIMqZGJcZd3Yh7cmmyfz X/GkZ8PEAV0plwEfq2VS//Qa7pUgoRBiYnM/17hRerQFOPNZKxeRjqj6RetQk9P3W5OLy0 Ix29aMQJ2ATzTO7FnI8jqXNELT6qKwc= Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-662-c4ixLJkCNd2SON5x2GIxXw-1; Tue, 06 Feb 2024 18:43:16 -0500 X-MC-Unique: c4ixLJkCNd2SON5x2GIxXw-1 Received: by mail-ua1-f71.google.com with SMTP id a1e0cc1a2514c-7cce403dfc1so3307816241.3 for ; Tue, 06 Feb 2024 15:43:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707262995; x=1707867795; 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=BKqi7t1q2HxhNGO8YhAm57zpm7GYMl8tE7F26XImgsE=; b=aTQ7W/KYFYYgJRnSVPWtJgne3sDfgfxC2EfrZPjRmbXGZrmGnLaWKdqeZAPotoEPSq rj8q3KBbnJ6npcrbhbh/s5uREgNLePqyYIVOzcItciyswjeLqYAbp9uzMUKKiDeY3lsX AtQwuN/tWXDvrVarTlR7c+nC+GMLyzXc+2Lpc+heKxYHuGb+SF3H5WukRfShRWqCWZSb FVH24hQV8IZIupOWwZb+Q9l7pj7/20lOClSLiKifw0dFx0xgEYnrwweFNqvPCF6UAh+g vMRxoSOZPyqWKMBepnpZcC5U4TC08XhUQ7DUW/SxBn1/jSC7KQ3DP7FNmmqVZbf/hH7Q 7VXg== X-Gm-Message-State: AOJu0YywFqdtczqLhKHPjkOkI1SP8XMGpwngGp2yiAKlveWQAIfDL0eB AjtI+Lh3SlkHS8kx1tiPrSfpEA4Wzo3CfnDTNgMsVehIyKO90Qwl3XGeHKlj1HEFctPyaCxSgXb dt5GSJhrDKdueo+GoGq6iJ30cNzEbwDhlHY5YS3k4XAXZNv2i3oLZKUiwIKT7ubuDsJmNhJweFG G6wOauGu8tabxwpiSCgTb29HQz8c8SJ5qxsw== X-Received: by 2002:a05:6102:3592:b0:46d:3368:971e with SMTP id h18-20020a056102359200b0046d3368971emr1269402vsu.33.1707262994829; Tue, 06 Feb 2024 15:43:14 -0800 (PST) X-Google-Smtp-Source: AGHT+IHK/bVHU7inbi2JuHbFzemHZknYr2Bz5VmtM/ti/vbrj7b13wnEQ7QyfNrXQAi+3YI2lNVBCxLXaBTn5/ZlI1Q= X-Received: by 2002:a05:6102:3592:b0:46d:3368:971e with SMTP id h18-20020a056102359200b0046d3368971emr1269355vsu.33.1707262994440; Tue, 06 Feb 2024 15:43:14 -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 00:43:02 +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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 9B1AB140002 X-Stat-Signature: bq8roxyb77iitox81worsirusxrounne X-HE-Tag: 1707262997-984223 X-HE-Meta: U2FsdGVkX18OFyiAz1ElUlahDyJCytx71/+Lppniu4vD4LKz1u2JvdMTfKO0SqCJ1r9C/1eKovTr5diCRl9vN3uYGvbGUIfFdJ36vpw8CeB7/xRsXw+E+At3Wlnv+IU6939bsWrdEOEEkpJHhvAHrNf97yw1UAOlhrgY/2N5SBZZ5yTgLq69pLLMAdY+bCj+h9ZfoeJQtcK6jnX3zNXdB7tAIGIm7tTPDTav1C98GWdRLEcdN0GLSpuSw2ZpPXUcRZUVhN9AwpMcTzOazvcvBuY9VdQqba3gjrJh/8QoyxuHkbmLcAQUfoLsI5LqM++j+6V3FkFWbfJJS8zyp8TdP/BOf5L0Y75/y1HzUnSJPtFmMisZsLKvv5iRVOKV/38yCgxxIw18tpvTVGqOB743OMSldoloRCqZVnd+L0oxONE+0YyEMh2TOHDaB8QcUX/EX6Dx5DajBAXJl2DTycM+LrPBhhQ4euP5Kl/LUzKcIsQvkCMVNdLA3LOQuu4azEo4BtP4NsiAVF6ut+jVB+ykyQScvIZtFX+HshTmNKl1luHnFDciNrojS27zFM7D827jlNJMwIB8w6WHK0Nv0HUbKQrExnXJYnbQIY/eUit8nDZovBloIX6oa0T4O1o8n1o/+/CB+Q7pjz+lsY1SZMtZjjeI94eSBORcGSX0zfb3nIyXdqGSvwT8ABfKhVad4o9S+D247RanBrjXmkZvuCOYqVNwmwcYkE5rzHdNesyLRdc/Vu0R/XZLmSG4BHsYXkXhg0yvnI/uYSju52f4cPqpUct/dwUkwSw3N411fA0c1OzhyP4qLhS/eVlmMnUdjk63AUqO1bf2ChvnM/WKmgxlmTSV/N7cr3iE/qLUAF9yjZZucIOiQpI/O8pz8M1U8onO406RwI3wHmH5JYNZz0Kj+stICfMfgQPfC5OaCQ+/0+938K5/c+0n+rVGAyd3pzxWyCm72ZO3jCDWs7Q+eqq hz0/dWII ucfY+sld1H968nw6/QuKqpZob7WLIEcmlMSxFfscBLtw/O1vtYKUU8oEBr5W3uqRBu2rrCPkaW1y5mp8PC171GsjynsPBRHpaiKxuK2RZJTUCv25GBEb5HGuPFGwA6XiZ+/p7LGIYTMGXZQW2/M8idF1TDlpEi2YOU+urD/sB9jtS0qmm776ZQP+UwRPJBknPr5EdErHpl7C2Si+hr7EAvRl4aYR49LhC8mJ+RHsf8ZgI5q0l2B7m1e+TAw/jBzQtXuZlYPhTbWd7tXsnl+qkoczkn7I32T3M6hZCpAb18kGbbtr6xGUhYhZ3eA== 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 Fri, Feb 2, 2024 at 11:55=E2=80=AFPM Sean Christopherson wrote: > > > > + struct kvm_sev_snp_launch_update { > > > > + __u64 start_gfn; /* Guest page number to st= art from. */ > > > > + __u64 uaddr; /* userspace address need = to be encrypted */ > > > > > > Huh? Why is KVM taking a userspace address? IIUC, the address uncon= ditionally > > > gets translated into a gfn, so why not pass a gfn? > > > > > > And speaking of gfns, AFAICT start_gfn is never used. > > > > I think having both the uaddr and start_gfn parameters makes sense. I > > think it's only awkward because how I'm using the memslot to translate > > the uaddr to a GFN in the current implementation, > > Yes. > > > > Oof, reading more of the code, this *requires* an effective in-place = copy-and-convert > > > of guest memory. > > > > So that's how it's done here, KVM_SNP_LAUNCH_UPDATE copies the pages in= to > > gmem, then passes those pages on to firmware for encryption. Then the > > VMM is expected to mark the GFN range as private via > > KVM_SET_MEMORY_ATTRIBUTES, since the VMM understands what constitutes > > initial private/encrypted payload. I should document that better in > > KVM_SNP_LAUNCH_UPDATE docs however. > > That's fine. As above, my complaints are that the unencrypted source *mu= st* be > covered by a memslot. That's beyond ugly. Yes, if there's one field that has to go it's uaddr, and then you'll have a non-in-place encrypt (any copy performed by KVM it is hidden). > > > > + kvaddr =3D pfn_to_kaddr(pfns[i]); > > > > + if (!virt_addr_valid(kvaddr)) { > > > > > > I really, really don't like that this assume guest_memfd is backed by= struct page. > > > > There are similar enforcements in the SEV/SEV-ES code. There was some > > initial discussion about relaxing this for SNP so we could support > > things like /dev/mem-mapped guest memory, but then guest_memfd came > > along and made that to be an unlikely use-case in the near-term given > > that it relies on alloc_pages() currently and explicitly guards against > > mmap()'ing pages in userspace. > > > > I think it makes to keep the current tightened restrictions in-place > > until such a use-case comes along, since otherwise we are relaxing a > > bunch of currently-useful sanity checks that span all throughout the co= de What sanity is being checked for, in other words why are they useful? If all you get for breaking the promise is a KVM_BUG_ON, for example, that's par for the course. If instead you get an oops, then we have a problem. I may be a bit less draconian than Sean, but the assumptions need to be documented and explained because they _are_ going to go away. > > > (b) Why are KVM's memory attributes never consulted? > > > > 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 launche= s > > they pages get set to private so they get faulted in from gmem. We coul= d > > document our expectations and enforce them here if that's preferable > > however. Maybe requiring KVM_SET_MEMORY_ATTRIBUTES(private) in advance > > 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 ca= n't > honor that, then we need to come up with better uAPI. Can you explain more verbosely what you mean? > > > > + * When invalid CPUID function entries are detect= ed, the firmware > > > > + * corrects these entries for debugging purpose a= nd leaves the > > > > + * page unencrypted so it can be provided users f= or debugging > > > > + * and error-reporting. > > > > > > Why? IIUC, this is basically backdooring reads/writes into guest_mem= fd to avoid > > > having to add proper mmap() support. > > Yes, I am specifically complaining about writing guest memory on failure,= which is > all kinds of weird. It is weird but I am not sure if you are complaining about firmware behavior or something else. Paolo