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 64072C10DCE for ; Tue, 5 Dec 2023 22:05:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DAD3E6B0074; Tue, 5 Dec 2023 17:04:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D5CEB6B0075; Tue, 5 Dec 2023 17:04:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFDC86B0078; Tue, 5 Dec 2023 17:04:59 -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 AF0046B0074 for ; Tue, 5 Dec 2023 17:04:59 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 79FC91A02BB for ; Tue, 5 Dec 2023 22:04:59 +0000 (UTC) X-FDA: 81534145518.15.C3AFECE Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by imf09.hostedemail.com (Postfix) with ESMTP id 85CF914000A for ; Tue, 5 Dec 2023 22:04:57 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JfHVXR8k; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.208.42 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=1701813897; 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=/xPsXYdPRuMVqnsmnQJ1p0ZibiDuuU0TYtGWS33ZgM4=; b=1vdA8aoxUyt1seMg6fssG5G6adZF8f26H1bIVdI9zcWBW4vypXyT46xQKVJTiN3Mybnmfo QgRJvBnlZYUdhg48Qa2EDh+8sEhdx5rAPKrWjHu8Mi6+XCpuSeedOUuw02ymJe5JQIgsqI UK2oUm8EU/lsuBUmeX2hoEsH4oWausQ= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JfHVXR8k; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=dionnaglaze@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701813897; a=rsa-sha256; cv=none; b=CFrPDXX7Zu6IED8C2yToeHwU5Ix/PQaEVx+c/V4cS1xW8n0GBI00mvbjYSK9/TN6PzarV+ i45OcHeN0cCm6HzCShqfczLSRtkTFOJUWeTzb8DykQ6grZdnxK3TqZfJC9UPoE/jhcVsfu yXaQ2i23tMfgXXGZ+YOcn+YM7Jldh7U= Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-54c77d011acso1151a12.1 for ; Tue, 05 Dec 2023 14:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701813896; x=1702418696; 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=/xPsXYdPRuMVqnsmnQJ1p0ZibiDuuU0TYtGWS33ZgM4=; b=JfHVXR8k3/X5A1Q0XnjZoh6lhvGDb2DTDMMBzefT46VSUU7BdyDbwlSiu/OcKF4XKB gj2WorENrXedkRjbgwjc54PZAxu/joR4VDQFHFLmoY5stJDTlSnGWLpMosGeYwuDQJct 0k9d8o984c0vQxes0Q3A8KsC+AWzh1wFLJMrJOWyvGpWqFeUWGQA4jRSF9xQSL9MGLEy wD16FXJwdUkLJumqZMpNw6UtCL3OEoUs99gDiDG63GEWQwKvfyAG/CFbsivza3wX2cnQ HiiCrn/fawznOdk0VeRcTMDPHg/tfAX2fSPafSwMw1aWEIwdRMZrpVyfN3kn0vuC/TS5 +LIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701813896; x=1702418696; 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=/xPsXYdPRuMVqnsmnQJ1p0ZibiDuuU0TYtGWS33ZgM4=; b=ldSc7FkIAYt0r5q4RydrLIYkO9mj3+UDGjYSAQwjgd2ayP4VJ+4OwRR8ANqUWJrgs/ Rt+ghzoD+OeGyRlEsq9y5s3mTDcJ/0BD0It0nyEXRqDCqWVRAhOk5U5Ib/EFZH3yfVVj SKqVLd9GWYjpO8ckA8kQYQtENu9vg8CQpFlzaYuS4Kk0yCO+CQR0L8V9m+L6l+DdlKLB o8ftPhOMg2QqTz3J4hE8BJ4QO+XrTsY3wV9ogRwShwer+DOS1bNqla28qHLTEO1NyurB UL5uDLXnHh3/io/hrDohvIylKCtEI5y2KfdhRD/Dksz09bynkB7W2VdBqrspx9+uUpp8 G71g== X-Gm-Message-State: AOJu0YwzITpBhCUaHSfgQYPgHXNK/DdKMInGRhZ4WZZPEeg/saO/j9tB eRfeoALCClnEVo4T8bjtxb1eX7aVtjBrKVgWpViqrQ== X-Google-Smtp-Source: AGHT+IEnOoiWY23KKyQjfRHwuGfX4CP9fcTkgpJltbeuMXUh11BY17rmT8TNGVgT5UIvk6dxp5zfegre0jIAWGh5Ggc= X-Received: by 2002:a50:bb03:0:b0:544:466b:3b20 with SMTP id y3-20020a50bb03000000b00544466b3b20mr5843ede.5.1701813895835; Tue, 05 Dec 2023 14:04:55 -0800 (PST) MIME-Version: 1.0 References: <20231016132819.1002933-49-michael.roth@amd.com> <20231110220756.7hhiy36jc6jiu7nm@amd.com> <656e6f0aa1c5_4568a29451@dwillia2-xfh.jf.intel.com.notmuch> <656f82b4b1972_45e012944e@dwillia2-xfh.jf.intel.com.notmuch> In-Reply-To: <656f82b4b1972_45e012944e@dwillia2-xfh.jf.intel.com.notmuch> From: Dionna Amalie Glaze Date: Tue, 5 Dec 2023 14:04:41 -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-Stat-Signature: qatjyobsoy95dnq58myg4unqrq8rzguz X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 85CF914000A X-HE-Tag: 1701813897-349843 X-HE-Meta: U2FsdGVkX19g7a4vUKGIvXDWHKcooLRmcUGGXe6w3JuZA1aIDuZgnaR4gKPcv464z7Ol4wDEDsckyWdV2A3FuQ2X5JcgvBNWR97M/XUSoMF1c37OnXkID0HDzsFGTJJPPRnZ7qQ1rov5Kg3+5fk6EMOc5t43obGhMhDyEhpIJ7wZr/eGKSAS97QHylEMUtRuGLmkBUcN2NOqvPWQri5Wp/lJgAFZHm2+t0wQ06CwXRi/WX7sqW/4FLZ99mw7oNlgPGKfW+MpIGOs5r0hNbibQn0t5qovrgxpNvia58zjHC//9fw5aHSeu5xeXZVgjP4LGXA6lAcys6wwxV14HbEsi9DkhSTtO8ZAZO3dXTFAH+b4ZYSifuVhh4l2MWY/SJh0RlUFFNJDkZ4AYT7isgYrw1Z6ne/02UxR1t9bJ3JI+W1TolmDdNqKgyh+bZBYJx0EN/bYPytnTuqqtZsE6Sfx6cfG0YNwZyUnsrbmHeBY/E8IDNO8p52q2cZk2qiJ49wJegt9oMhRqkSRJPMfehQUDN83Z8a22uzOGkgNQbfrO/LcHUHuBjrD0O+bC3wkLw3ejZ/+SpBpP7ECLqoUjUpj2qByro7VsI0sa+LARVudlGS0wfjy8UVYuWB6USWhxwVFrg8uh1rMDAZuiTXVyYKUiJcBJ96jwjX1+iKB7FUxenDQkX6sjQk4BH4DtCZVj681KDIYOrMgBy5JumZ2CfjhHCekk9hMRuNnHdxLejLnJ7UMrUocjHblPe+kxPp5xBo6CVx8vmgopTymfBpoYwo511ztVqbtXMt4uywkW6oOPSP0pJ5RJlSjMdofQE6yI0nK4jIUiZXxoD7ZYJnMNjAkSN4Bh7S7bu+Ee7JF3NnOEOwJVapcGW9a54EkXNdVGTDkgb8csBWd5eZgBrov6mcp8qa4BNT981Wa2itJ+zX+uoZBN7ZBVKSWhBrbbLyAqPuAaUVfxZ2wqmSckGQjH4t 3y9T0hJH mMSdgEyI/bya8nYTF/sRfqBzaPLlhXCzGrahFnh5k+FBORRRTAcoz/GB5Neax8y5Z1Ro9eldc5xWLZ7F4Qqfrcinsr+AASjLOI8C0Y0Eo5OdOio7wfREReCXs6U+7qCLu2RPrCE4PuQHaPLrnHRKZu23JCqk5NV1CVvysZ6O6/8ZgW32EMqxEBK5IBa2PgBOhBwHmqR3DvPmx5vW0O05yE0zOeElb+YbHwTFqvcG3tvlKSQXY2bRAQ+vIFkh6hcC2QR6KWedvVkVxBvA3G87EEGyQz1p4MeQRKumuqPpiNesAjwIraYGybsDwHw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000010, 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 Tue, Dec 5, 2023 at 12:06=E2=80=AFPM Dan Williams wrote: > > [ add Ard for the SBOM sysfs ABI commentary ] > > Dionna Amalie Glaze wrote: > [..] > > > > 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'r= e > > > > looking more at an industry alignment on coRIM for SBOM formats (ye= s > > > > please), then it'd be great to start getting that kind of info plum= bed > > > > 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. > > I wonder what the concern is with mounting efivarfs vs configfs? In any > event this seems distinct enough to be its own /sys/firmware/efi/sbom > file. I would defer to Ard, but I think SBOM is a generally useful > concept that would be out of place as a blob returned from configfs-tsm. > > > Still there's the matter of cached TDI RIMs. NVIDIA would have > > I am not immediatly sure what a "TDI RIM" is? > I might just be making up terms. Any trusted hardware device that has its own attestation will (hopefully) have signed reference measurements, or a Reference Integrity Manifest as TCG calls them. > > everyone send attestation requests to their servers every quote > > request in the NRAS architecture, but we're looking at other ways to > > "NRAS" does not parse for me either. > That would be this https://docs.attestation.nvidia.com/api-docs/nras.html > > provide reliable attestation without a third party service, albeit > > with slightly different security properties. > > Setting the above confusion aside, I would just say that in general yes, > the kernel needs to understand its role in an end-to-end attestation > architecture that is not beholden to a single vendor, but also allows > the kernel to enforce ABI stability / mitigate regressions based on > binary format changes. > I'm mainly holding on to hope that I don't have to introduce a new runtime dependency on a service that gives a source of truth about the software that's running in the VM. If we can have a GUID table with a flexible size that the host can request of the guest, then we can version ABI changes with new GUID entries. It's a big enough value space without vanity naming opportunities that we can pretty easily make changes without incurring any guest kernel changes. --=20 -Dionna Glaze, PhD (she/her)