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 72263C47071 for ; Thu, 16 Nov 2023 05:31:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A68836B0416; Thu, 16 Nov 2023 00:31:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A17B36B0417; Thu, 16 Nov 2023 00:31:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 890B46B0418; Thu, 16 Nov 2023 00:31:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 754FD6B0416 for ; Thu, 16 Nov 2023 00:31:51 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4551C1A0BE2 for ; Thu, 16 Nov 2023 05:31:51 +0000 (UTC) X-FDA: 81462695622.05.80ACEB0 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf27.hostedemail.com (Postfix) with ESMTP id 8C91240005 for ; Thu, 16 Nov 2023 05:31:49 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=TVC6vOF1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=dionnaglaze@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700112709; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4diCtTL3EivIaKd6Yrty+RIJmvtzTDLTo/nXfRxccPk=; b=0xVv4oDuoci5QpzJTGQG/T5zsEM+FwFF2OMA+3KsqCpHH+gFtCkwDhX1eXu/4dxSGHmiCT gx1TjTHMJTey+0vVAMch81QaDCH7MZ96/fSgnuy4hKpEOdSHatEdRr5RiOIPNGgcPWuB3Q XRexL1wnpZ7rgKjnDvL9u3wa85nuCQc= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=TVC6vOF1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=dionnaglaze@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700112709; a=rsa-sha256; cv=none; b=65w3Vkdngt3XRQBgozkVpxwn5HT70QxPEPyFmRvsKlVoyG6SnOSublHxWAxAMVA49B2TXa y6YuZCIDN0sJNE8wzJ05RBLr7gMrAt4ay841yOxfOR0P2NbE5BeDZXbmR/VWbDUtX1qPZ0 LcJEuT3u5M/xVq3uwgNrxGn0dCWeTvA= Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-545557de8e6so8119a12.0 for ; Wed, 15 Nov 2023 21:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1700112708; x=1700717508; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4diCtTL3EivIaKd6Yrty+RIJmvtzTDLTo/nXfRxccPk=; b=TVC6vOF155Hc5gQG+jOTvsEKXWPZSgygSOf+U1h4mvaXqwPs29GBVm/lBD4raUj/67 RFimX5aTZYxEqoS9RjOR5kTzDN/SZ+xW6GvnocYxuF6I9SDZlKNkkPrtc7QUtaIPPYQH IE4A7CjNdpDWX8Mv4U+1Ubf9/MTMkMWkezruua2CBDx0rUIj8eeQ+ccr/H+jZdSqSaZA hMBbztlabouJ6DgOLjP69xVwQjg/d2Z7C2/u89mYEwYU/cdvFzCtQuPRpvOia9AH6Llp TFNVyb7ym1m+8BeHlbCeoH8ugZBEl5C5dqxHHAXR2ekByGocbT/4l6uGfcT6BdBGkJpH sFZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700112708; x=1700717508; h=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=4diCtTL3EivIaKd6Yrty+RIJmvtzTDLTo/nXfRxccPk=; b=hQECng70hS7oYgOnAxDg+SC/dm0h9IBbDiovM3Rf80geD2he3mOHCL1SLdXcbzCGx2 RkHQGbvKW2W0HQVML819R6lMpoz1mq9v1gkKotHYNqo9x95uAmlrAD9NQYdC4Yobeg8d v44U/WLcR+LGDE9bbBcR08DgAq/r2INk/2ppi2nJmp0SvGjwyExrQU2DmJJ87E9kg+Jk TdcFVvPd5Gpp85m9pJ41OYWmMuJxwXaLuOUfn9ZFoJ3PbKbUGTcoZ0eoSrtqBMbshpIq wq5/vq6clm8tk8uTZ9QQjY548loGV65YF1iRk71CTARnaGXYSC3exUKSEAeWsHKjgzyN FmEQ== X-Gm-Message-State: AOJu0YzsAghW5kt4QV9lZjQZWMl0SaaOGfGy8ePHu2/GijBfFribjHoN k3BB59Qca2xhjg/3gPrpAKy9E9e2AebLJVwAoz5pgA== X-Google-Smtp-Source: AGHT+IGOHarkPwgABVlEMIKneg9bFJeC/Sizgt1g86eNBkXhc6lGj6UX9Rcz+JOCTeiCxNp2DrA60v/aOwz4dSqmSxY= X-Received: by 2002:a05:6402:1bcb:b0:547:3f1:84e0 with SMTP id ch11-20020a0564021bcb00b0054703f184e0mr60685edb.7.1700112707847; Wed, 15 Nov 2023 21:31:47 -0800 (PST) MIME-Version: 1.0 References: <20231016132819.1002933-1-michael.roth@amd.com> <20231016132819.1002933-49-michael.roth@amd.com> <20231110220756.7hhiy36jc6jiu7nm@amd.com> In-Reply-To: From: Dionna Amalie Glaze Date: Wed, 15 Nov 2023 21:31:34 -0800 Message-ID: Subject: Re: [PATCH v10 48/50] KVM: SEV: Provide support for SNP_GUEST_REQUEST NAE event To: Sean Christopherson Cc: Michael Roth , Alexey Kardashevskiy , 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, pbonzini@redhat.com, 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 , Dan Williams Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 8C91240005 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: tb4tgdesamc69gx93ouie776gqqjdx1g X-HE-Tag: 1700112709-870485 X-HE-Meta: U2FsdGVkX19zs/kMCt//BzTB1SshzIlom0flmjK5auH1bGRHtIPwDF3TV/f2WLl/5b+NmcsooAvemzsOVT8QL6EWjJgF+hfLZ76A4W93yvsJsT2cTKK+xAHekACviKDwGftuXDzT2zQepoX6kqvv87DwjS3lEGSwQJsNS4qJ10/qnWbJzI7eXBh+Ee1cTvJ8VA/JRW2ISK1oDHiOasL/Dz5J8xhCC8LrA6AFa5s6waQzeDXaAPIQAHGRJ+1p3AWyYnf5KGJpl9boKhqmWXes2ZuBNKP76HyzNjV7Ign2ukejwaqHsfOZg5oDvT305KKVJrfRro82p371CKASzDmSlHOXzUSdllNNfC6MBbV/Leowm2K4XZCg1b7rirOje77EsGiLqKRNH8wEI6l3VPebUsqgwLZUIpBW/GthTy7+k88UMaWoIvzuRtRNwig06qxb/a6DEivzPioBYr1HhpqbHGT+qlolbHOk0aaF8Uw1tsrp1FgBCPFl35kT1F4uD4uNiNbWM+R+tPp38d+hXGLXNjHK49Qx8woKGLDhODfSHc4Ta3Ez73bvAJdF+BVuDUMi3ewp/O0IM18d0StF0LOCV3jzJWEYFzNOAwMITTgffNMFCFd3yEbyTdniZNJM6yJe6PDbstWLailmLwIyYNnhbWnwaJVgVVmd446Kb8ecqpKgR5gqp0ENMNbRr2o6AVIKpBNv+TLgVeXvWdwAnHcQ0UxWN/7TGzArSLQOB79cEES3UJ0SDoywHWtotP0wj7mGzZ2QwhHnDhhyiFUU3PQItjb+ikM3JnQ0k1N790gg9WcY1bs4FJyGU28CZZhDxbyKKl/CJlTXsoChxdQ2q93GkrTw675iux6WTRe9sDdp8J0jp8i8mFs4xAkZCiizSFLPiMwToIvp41cT7y9GZa9hG3FVW/aABsvOeZNZQRmjeamejuPa8ubEqT33TmYe0+24sz2b9bk0a/tZPphCWsn x/4RXy55 yTqCXGsz6gDff/qRS8ilaqya65uXzSXYHX47GwNNZyj4uw09GuzuLn5SF4iuf6N1qCj9TeEuWNaFrwZ3b67qQAEiCwMYZRD1XUfXW/3ufnw1SKooRVd8J3s4428P7Gm91xqUxMi2y/cM/bpUtOzUt/X/1jgDRAldZPzVcsKEc4ZNlavu6ydej7uHqROsmIksj4ZcjcwOnLIu5k1WLdn+I5n7j+dqF9cFSR9tO98hCYHUOYnrJEmEuN0gWQAvASDFfV3xxbZk6T0dSFBKbzbLGAdsjESjd5M9J1fLt2rZs9KSKfZnYT2PiRjq/BF7OIz7TYIxMEKWxE+RnzwKyOBQvdIeWWlyvA1eWlTBKjpRFSLjGfJA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.007465, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > > So we're sort of complicating the more common case to support a more niche > > one (as far as userspace is concerned anyway; as far as kernel goes, your > > approach is certainly simplest :)). > > > > Instead, maybe a compromise is warranted so the requirements on userspace > > side are less complicated for a more basic deployment: > > > > 1) If /dev/sev is used to set a global certificate, then that will be > > used unconditionally by KVM, protected by simple dumb mutex during > > usage/update. > > 2) If /dev/sev is not used to set the global certificate is the value > > is NULL, we assume userspace wants full responsibility for managing > > certificates and exit to userspace to request the certs in the manner > > you suggested. > > > > Sean, Dionna, would this cover your concerns and address the certificate > > update use-case? > > Honestly, no. I see zero reason for the kernel to be involved. IIUC, there's no > privileged operations that require kernel intervention, which means that shoving > a global cert into /dev/sev is using the CCP driver as middleman. Just use a > userspace daemon. I have a very hard time believing that passing around large-ish > blobs of data in userspace isn't already a solved problem. ping sathyanarayanan.kuppuswamy@linux.intel.com and +Dan Williams I think for a uniform experience for all coco technologies, we need someone from Intel to weigh in on supporting auxblob through a similar vmexit. Whereas the quoting enclave gets its PCK cert installed by the host, something like the firmware's SBOM [1] could be delivered in auxblob. The proposal to embed the compressed SBOM binary in a coff section of the UEFI doesn't get it communicated to user space, so this is a good place to get that info about the expected TDMR in. The SBOM proposal itself would need additional modeling in the coRIM profile to have extra coco-specific measurements or we need to find some other method of getting this info bundled with the attestation report. My own plan for SEV-SNP was to have a bespoke signed measurement of the UEFI in the GUID table, but that doesn't extend to TDX. If we're looking more at an industry alignment on coRIM for SBOM formats (yes please), then it'd be great to start getting that kind of info plumbed to the user in a uniform way that doesn't have to rely on servers providing the endorsements. [1] https://uefi.org/blog/firmware-sbom-proposal -- -Dionna Glaze, PhD (she/her)