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 2CCFDC4167B for ; Tue, 5 Dec 2023 00:48:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A63AA6B00A2; Mon, 4 Dec 2023 19:48:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9ECA86B00A4; Mon, 4 Dec 2023 19:48:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8675D6B00A5; Mon, 4 Dec 2023 19:48:49 -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 729436B00A2 for ; Mon, 4 Dec 2023 19:48:49 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3FE8BC0495 for ; Tue, 5 Dec 2023 00:48:49 +0000 (UTC) X-FDA: 81530929578.12.377B267 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by imf19.hostedemail.com (Postfix) with ESMTP id 478101A0014 for ; Tue, 5 Dec 2023 00:48:47 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=CP0b2dl0; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=dionnaglaze@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701737327; a=rsa-sha256; cv=none; b=YmRMIlmVvWr1dLYzmSLJBemlm89R4J/Jc/aJA1Q1Oq//wpyxjvPUofE+XWssY57KFTTs8F dMP5GzaJy/6Ea9OMoy++Q2Z/D6mYGEVDtR/PHeeY7PyVraqsLBvCDVjBgb4T/XhfNrhUUK u+ic7bGTuLXvsaMgkF7mI/kXToiFHJA= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=CP0b2dl0; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.208.44 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=1701737327; 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=lxuWs5WeL5blIKEEZ0dpXLc7B+HhRdY1WEpcCPigzSk=; b=6jTBJmyn+kthU+WdtG7eS1un4BGxMIsCwXfHiWe8aVoTrGTOwRgCSh3/yuvX2lY8gNqwkR GJ+7WuEzS67k3/6WcswlZ6GHYrIizYLh3g1Inx8Olrp9UHCJea5WJeb/TKHqIG2u43SP0M QA3pUBd3gMzSIjVHZCrO2bu66qf1dEU= Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-548ae9a5eeaso2696a12.1 for ; Mon, 04 Dec 2023 16:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701737326; x=1702342126; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lxuWs5WeL5blIKEEZ0dpXLc7B+HhRdY1WEpcCPigzSk=; b=CP0b2dl0TqTX6brpvwYLUlN0ZBCmUShkXk4qoCB/hdZRsnQe+xKSrLJrIea9XatFbw 2aCp8JkuV6WfGklf+fIh0R4q3FM4fx4ETV9n4Ps5xnQjwwEojXdVHas4vvg6yqNrnySt 84Du3ADIamILE6TMaTUlyZ/G02QvC6btMzMhTKlLiOCPkQAuIcB987EYxeNe+8nt2vHf muILOPgKRcRoswj9k9D+mDyFs8MsxbEzx2va6CfP6j018GgnaBoUTM0bif7xyj4DqRbU OQZHfkpKj1Ic+nzgEKxed57DglQMOQ9MvR9BrAhV/dgDFI9i+tRLZyDiJeDky/uwEcR2 CbDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701737326; x=1702342126; 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=lxuWs5WeL5blIKEEZ0dpXLc7B+HhRdY1WEpcCPigzSk=; b=QOGIyS6DxDhdoDxMpWYzizHx/VcZRShICAAqecyBZdAYLxyiFTZ1pVQmVqSqzCEUco pQ3+CtA5WfbeFN7rqz8Aju32azyVqF0LrtI0Z/LQiSVM0t+Q2OMTeERCMwIb73x9ZdbP kk3BBP9T2+gaf23gROQIGDC5vXgT6kOqslsKD70IHlLrx3jZdI6Pm2BmUETRWwA/0ta+ rXDI00Ih5QDaDfWJc+bbE6tsHCANPwGAtYhJjJ4dEn6FLjQicCZAfnpcVc1jbT+bW2xT x4qWPsZKlVIUyL/UaDgt4D2jltHDr8foastiFiDzaJYv8MXWbfMwdoAiYCE7ATa+4HZG fGaQ== X-Gm-Message-State: AOJu0YwXpivPzZN7KJxiPvzABmydYyxv00RdCj7Dx3WL8csHyvNi5TV5 pfViq6s9we1QB8BfVakGq2vYcHnRVNc0iIDyGA97Sg== X-Google-Smtp-Source: AGHT+IGNw6BJISL+mPyQWP6VVQrK3THTpaodyhZoX81SuXtJCkb6I5Bmu7qpxkCPOCxVqNpCxDjzVMVB553aAyN2eNY= X-Received: by 2002:a50:bb48:0:b0:54b:bf08:a95f with SMTP id y66-20020a50bb48000000b0054bbf08a95fmr474310ede.6.1701737325590; Mon, 04 Dec 2023 16:48:45 -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> <656e6f0aa1c5_4568a29451@dwillia2-xfh.jf.intel.com.notmuch> In-Reply-To: <656e6f0aa1c5_4568a29451@dwillia2-xfh.jf.intel.com.notmuch> From: Dionna Amalie Glaze Date: Mon, 4 Dec 2023 16:48:34 -0800 Message-ID: Subject: Re: [PATCH v10 48/50] KVM: SEV: Provide support for SNP_GUEST_REQUEST NAE event To: Dan Williams Cc: Sean Christopherson , 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.middleton@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 478101A0014 X-Stat-Signature: rm3q3pdnjhz8ogthrs3b37nbthwqe1y3 X-HE-Tag: 1701737327-881463 X-HE-Meta: U2FsdGVkX18cY0Dyt+KR2k9LBCcWHyhfHZ6bHxAOQLqsTnjvUQ4st2ehZzo8IV1Y/IMeoWdHsSF3xWZUlVKxOrfqVR41c/BytXTSovT24GEqmX99e7PIk1TwTRTS/JkG5NAFJ2E3BGcheCv99qzRuJM8X8xeKfonvCYJo4fjNIO+7Sc+8GkgUq6elRDerP1RImZIZ+9YWIwAwX2Fa9WekaSz2yYHPNNiECQZUSWIQD8RI9xi93J1634vNM6LiAHmsCST5yQJ4jIzdS0PG+i+re6/7ZqwbfLPd2b0sBkzTnLZ/2x+EIz1tlTPA5DBGpj16TBbn0kGNZePEIimYVWXyPpeK4d0LzPlinAyGL1sXDJNA1A+ReUBXrXLp0frq4bUBbrqTdSzW/QOcy1fl/BDRdfw6P1i37B71VTFzh85nOobN/PnOKuM3S4VtuQo7Nach1ZPqkUsSMWDX5qldkVd7zKiGSkFRMfsIsUPsPImgBJRY9N5n13pHLxmbCUW2Gu8MgHjMdF593vgCo0OfqVY0wY+tOyyNhQfRMI/Ofme2SmDPK4LhR7X4SakzbHDFnvKuhFeMuRNlQNvty9VPF6YuO6DtrabKo76Egi1UY/ooNCbt8/nrbN+ohvbhd66N54mq9bzlSMy3fmGXcTi0XR8fbV6qiW0t08kzO6Nu6jjTAts3BaYL8MSnYfIHmQT7NcQ7dCOvASY4zxTf/EWsh5K1BY0ElWTfNTlctd1RG/ZhnBZmsD5FglEfQvqC/jn28sg0mmp+cv0SVzok6hpu8HcDqT3bxroo8Vflx/bOmqLeQ1NbW2PL1IcU0oJBdu0DGTPTgVq5bjmoqrFSgPcDyf4KRQofGUzBWgeNxHKBLH15eS6buOzsVrsT4lPROgT1sePLcjgwtdMLIbMjfFKKCrarxRsl7mEKlXyn0c4uF4TlJWCbCgrb1isB9nxCA3YdDwyg7MPaye1YGDtfGZMwC+ egrb2gtZ 9WOxJDUNmpKBbVmpacTw1qNNbCP+2OLjObhpdBvWbtYXt+eX42Y/xySE4yoObqmII+oq5Ad0iE2nsQr6R+r81KEPyNBEZDWmi5Xcpt5TqS0lEy8I3gWqJNLTe8j0aZSlFr95YfusWfdu0iauTIHxgVa8s4PGF5InmPJ+hMDo4ALUqau1TQ/Fe7/1UI2YxjJm1Ud9BDqryNc4S9BbpumX8kL+Iw5O6aYdxTVZMaPJNzBBW5KtvFwuVx/TcS62sQkLM50/WHlvAFutJt1s= X-Bogosity: Ham, tests=bogofilter, spamicity=0.002074, 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 Mon, Dec 4, 2023 at 4:30=E2=80=AFPM Dan Williams wrote: > > [ add Dan Middleton for his awareness ] > > Dionna Amalie Glaze wrote: > > > > So we're sort of complicating the more common case to support a mor= e 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 use= rspace > > > > side are less complicated for a more basic deployment: > > > > > > > > 1) If /dev/sev is used to set a global certificate, then that wil= l be > > > > used unconditionally by KVM, protected by simple dumb mutex du= ring > > > > usage/update. > > > > 2) If /dev/sev is not used to set the global certificate is the v= alue > > > > is NULL, we assume userspace wants full responsibility for man= aging > > > > certificates and exit to userspace to request the certs in the= manner > > > > you suggested. > > > > > > > > Sean, Dionna, would this cover your concerns and address the certif= icate > > > > 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 t= hat shoving > > > a global cert into /dev/sev is using the CCP driver as middleman. Ju= st use a > > > userspace daemon. I have a very hard time believing that passing aro= und large-ish > > > blobs of data in userspace isn't already a solved problem. > > > > ping sathyanarayanan.kuppuswamy@linux.intel.com and +Dan Williams > > Apologies Dionna, I missed this earlier. > No worries, I've been sick anyway. > > > > 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. > > SBOM looks different than the SEV use case of @auxblob to convey a > certificate chain. The SEV use case has a GUID table in which we're allowed to provide more than just the VCEK certificate chain. I'm using it to deliver a UEFI endorsement document as well. > > Are you asking for @auxblob to be SBOM on TDX and a certchain on SEV, or > unifying the @auxblob format on SBOM? Given SEV is both certchain and SBOM and TDX doesn't need a certchain in auxblob, I'd just be looking at delivering SBOM in auxblob for TDX. It's probably better to have something extensible though, like SEV's GUID table format. We may want to provide cached TDI RIMs too, for example. > > > 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 > > Honestly my first reaction for this ABI would be for a new file under > /sys/firmware/efi/efivars or similar. For UEFI specifically that could make sense, yes. Not everyone has been mounting efivars, so it's been a bit of an uphill battle for that one. Still there's the matter of cached TDI RIMs. NVIDIA would have everyone send attestation requests to their servers every quote request in the NRAS architecture, but we're looking at other ways to provide reliable attestation without a third party service, albeit with slightly different security properties. --=20 -Dionna Glaze, PhD (she/her)