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 D2C08C4167B for ; Wed, 6 Dec 2023 00:43:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5E1816B0083; Tue, 5 Dec 2023 19:43:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 592D96B0087; Tue, 5 Dec 2023 19:43:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 480B46B0088; Tue, 5 Dec 2023 19:43:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 3770E6B0083 for ; Tue, 5 Dec 2023 19:43:18 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 16426A030B for ; Wed, 6 Dec 2023 00:43:18 +0000 (UTC) X-FDA: 81534544476.27.35A284C Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf22.hostedemail.com (Postfix) with ESMTP id 43DB7C0016 for ; Wed, 6 Dec 2023 00:43:16 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="d/3JnTLa"; spf=pass (imf22.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=dionnaglaze@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=1701823396; 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=0CGpNMJzqHfBBmrth6e1MGteUUzf7hdy/lyzvmA95dY=; b=Z8rQ6M2YObUx6D5lWx1QBkAOIzr2ewvE6eoH/3yT9WdO5VlIsedGprbI+TSsTPkGeM5DlD lcoC8Ky6HBPpIXg6Zara2IuTbdc5RAKlr23E294SQ3F5iYABPRIL+uxVUQpOtXStgwXQ6J YZFAQ4XISLG7xdwK6rQ0h4lKkTIUfgs= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="d/3JnTLa"; spf=pass (imf22.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=dionnaglaze@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701823396; a=rsa-sha256; cv=none; b=Ad/PB1FBQo+EGgM9rKP7YobrtElfARMBWezl8eYIq1ptVgylatFVfZwurc/1A1Qh76oqsw hUc+nMI5gYb3bdL1u17UoqP98VHFR3iBtF6p65S7pa2QizTwLlm6K8KmptxXkFT0Zit+8L lbiMruCcrIBABsh8XvKQHSAWObQylEQ= Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-54c77d011acso2660a12.1 for ; Tue, 05 Dec 2023 16:43:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701823395; x=1702428195; 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=0CGpNMJzqHfBBmrth6e1MGteUUzf7hdy/lyzvmA95dY=; b=d/3JnTLagWu7Mgtul/jz/vAA7oHlPNRLCzaqb8MkfbIMGHHRuh5oBZm3iP8fanvRjM z1xII7mrY0nZjxTftFxFhXG+7WG7Cj23NXAght1u2oORwgf2BGpmUlfu6T1M+0LjhmNh 4ad1ckf4uy2zjF4tbCAjXRnz9CnkCsDpXDQKxDG9/j8VBAmA93PPfOFfvh4OqZc31Zq0 HKcEIZqLcAymXxqaEieq3afQAA8hWKVL4qFnwb0OkI67qD//P2UVqZTMPPaQbTltxRql TAOyVDZbbYvvxk1g233BpH3wkoRJMYWGFzaPfHXqWq1fLM10/jxN42nwbzaXJz8eH2Xs qoRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701823395; x=1702428195; 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=0CGpNMJzqHfBBmrth6e1MGteUUzf7hdy/lyzvmA95dY=; b=fOUD6hHskCEiSa9ASGpo+WeHFs8i7owvdAg6k3hP68pz84mpV4XJ0X3o/P7x7UuEl0 SwgUitf+0GWSt3R4WgRFyK/MuIl32pQeNQi7rsYppYb8s6vBdO3UUz6nB47D9NMs1iCd YbaOvOvhRaR+GeZUWPv4LhkUswhUo0YpwTqLcy33HX2nI2YDeLkmosEVr61d2Xa+wQhN OaOMzAHyCljt3Pj488GLNCJ9POO6XpyjhRe/SI1e9Loa/EOoeyfxzkGZh7PZvQrKlQa9 oZmXcv+v1JP0iH89AXQCQ8vUDX2xai3ful7bEuWpRV0xe8irjQOkPwtPpm9rXfMr+Fi2 XAiA== X-Gm-Message-State: AOJu0YxagCV4BfxXw6NnPVHUu2bAhhGLYugmuavb0sxak3YXLONk6t9t HZX4Zq0D7YQPMRz3qzB3odt09MDJesOzLphvuv2O1g== X-Google-Smtp-Source: AGHT+IHnxQI+DCFCxmScTp7bseun1ubBzYz2vloVjxDiicjaclByuyc4HtX+jd86aOQ5xnHQeVkN+gBTvB5g8n8nI7I= X-Received: by 2002:a50:c35d:0:b0:54c:79ed:a018 with SMTP id q29-20020a50c35d000000b0054c79eda018mr44800edb.2.1701823394564; Tue, 05 Dec 2023 16:43:14 -0800 (PST) MIME-Version: 1.0 References: <20231110220756.7hhiy36jc6jiu7nm@amd.com> <656e6f0aa1c5_4568a29451@dwillia2-xfh.jf.intel.com.notmuch> <656f82b4b1972_45e012944e@dwillia2-xfh.jf.intel.com.notmuch> <656fae221bf90_45e01294d2@dwillia2-xfh.jf.intel.com.notmuch> In-Reply-To: <656fae221bf90_45e01294d2@dwillia2-xfh.jf.intel.com.notmuch> From: Dionna Amalie Glaze Date: Tue, 5 Dec 2023 16:43:03 -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-Rspamd-Queue-Id: 43DB7C0016 X-Rspam-User: X-Stat-Signature: cbwzeto3xy14765ygbq8p63f8tufp9ke X-Rspamd-Server: rspam01 X-HE-Tag: 1701823396-999518 X-HE-Meta: U2FsdGVkX198IL3m5xQ7AsisSUCtE1aN60387mb1qW9V50D+YLufkFBff8f9o7XLllP6NC2wVMPNCd4PG9vKSFLevZlF4bHS0aGiVZ7FmgD7qYC7v/hTnzUjC4wRKSEysTdg071CXfIfZK4l0dTP+/SAAZnNJz2ouow2B2d9tIKmLtPHfhs2qpMIbXFYw+yXTX4KhEN+is86uIl9NwyoOc878yYE2Kz1CRX4CazCJWcRvu0/kGomSmN3hxhHCQkeRUwPm4GYqLMRHTuGW5LnvIDI0p98J6ZKti/ZJEjtDyGgKdgei4f5XX2zMwRGkokogE5yZaXoWqHKpzvjKqRw+Pr3h3asTsdYlh/vC9PQ80ioENmZsH34EsGLKHCwuxTbgvjdVjB6ma+dSgtelDS9cMf1ddQZC7QkC5n2U2lL4oKhsZ9EKVwyobtSynle+GMspqAz0AtmoU4u+kquEny4ucF4pNrSpc6QwGKAaZzxbq59cSanmZSTKxQKpuNS8Jr3DCmYgBUb/OHtKeFKKq1eMXoYzgMiYMT7BQxCFgq98Pf0nRtLih580JxL3W+Zrcf1oj6+ugshQgUiDdhcbKYdXw2EsqsuodCxNsEaT8Kz6bpkPk8g2gS4obWoDxLMAjCXhD3cAsATQYqgTYMwzyT8biUMNAtmJTTyUa6DLp5dVSTbc+nXykWFq5Zryol7QczUIwnLHmLSOZgirnnSXD+UFmdIUdRnlqQIjYotEn4OM8crllPfvzkzdmkxN6HVXyXsTczemaR6T8qvyvi64k+IisjtEeNvblqIimgyzh/lsSwnPY3D7+ljzMWMsbKajICPISeHBnnRDOwRGuhsRQ0nOarhNRp2itb0vJB4IlnvsbfqF+1xG1gAU8rx/4VzySohY46+DzUTiMHNuKvrY+E1DDIjDpNkQZl2/F9KtNfsIv5krNvWW16ytzBmKFw9as1Q5EVGILELGjN8tmuqbnU hN7MkAFP ESi1xMA2+/nohZJZ8TSk1GOE2TVUA1wAYSOS/cboAwXKWXmh2IaQ5bMN23OyUuD2hXAQ1lJm4LSA5/1X8gqXoR9y4EbGUrT60A1EdS+rhv6WvZFrkzXIY+nmJlNpuiHUPlnSgONRczbRhWWj1nE4g6B5yIT3eux5Ce76Yv6ZVj8E30z6VdDnk06AWtpTz9GutXef15HvVG9WnBo+OLS5yXSUGOJHlE40CdTravj+Bj9t8DiDmrgnIudpRey3GMYtc9z8mymYsYBUndx4r+K3AqEaN5tesXbeDyMuPk6/L1BEKwyw= 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: > So it's not only SBOM that you are concerned about, but instead want to > have a one stop shop for auxiliary evidence and get the vendors agree on > following the same GUID+blob precedent that is already there for the AMD > cert chain? That sounds reasonable, but I still feel it should be > limited to things that do not fit into an existing ABI namespace. > The tl;dr is I want something simple for a hard problem and I'll probably lose this argument. The unfortunate state of affairs here is that it is "vendor dependent" whatever pathway they choose to provide reference material for attestations. Even with the RATS framework, "reference value provider" is just a bubble in a diagram and not a federated service protocol that we've all agreed on. TCG's recommendation for delivering the RIM in the efi volume doesn't quite work in the cloud setting, since images own that and not us as the firmware provider. There's no standard for how to inform a user where to get a RIM other than that :( > ...unless its evidence / material that only a TVM would ever need. There's the rub. Evidence may be provided to the TVM to forward to verifiers, but really it's the verifiers that are tasked with gathering all this attestation collateral. The TVM doesn't have to do anything, even provide machine-specific certificates. That's pretty dreadful system design though, since you end up with global services in your hot path rather than getting cached data from the machine you're getting an attestation from. My first stab at it is to just have a storage bucket with objects named based on expected measurement values, so you just construct a URL and download the endorsement if you need it. I'd really rather just make that part of what the guest can get from auxblob since they pay the bandwidth of forwarding it to verifiers rather than my cost center paying for the storage bucket bandwidth (is this the real reason I'm pushing on this? I'm unsure). If you're instead asking if this information would need to get piped to a non-TVM (say, a non-confidential VM with a virtual TPM), then the answer is maa~aaa~aaybe but probably not. PCR0 in the cloud really needs its own profile, since the TCG platform firmware profile (PFP) is unsuitable. There's not a whole lot of point delivering a signed endorsement of a firmware measurement that we don't include in the event log anyway for stability reasons, even if that's against the PFP spec. So probably not. I think we're pretty clear that host-cached data would only need to be for TVMs. If you ask the folks I've been talking to at Intel or NVIDIA, they'd probably say to put a service in your dependencies and be done with it; it's the vendor's responsibility to provide an available enough service to provide all the evidence that an attestation verifier may want. That's quite unfriendly to the smaller players in the field, but maybe it's easy to integrate with something like Veraison's endorsement provisioning API [1] or Intel's Trust Authority (n=C3=A9e Project Amber). I haven't done it. [1] https://github.com/veraison/docs/tree/main/api/endorsement-provisioning --=20 -Dionna Glaze, PhD (she/her)