Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Date:   Tue, 5 Dec 2023 12:06:12 -0800
From:   Dan Williams <dan.j.williams@intel.com>
To:     Dionna Amalie Glaze <dionnaglaze@google.com>,
        Dan Williams <dan.j.williams@intel.com>
CC:     Sean Christopherson <seanjc@google.com>,
        Michael Roth <michael.roth@amd.com>,
        Alexey Kardashevskiy <aik@amd.com>, <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 <brijesh.singh@amd.com>,
        <dan.middleton@intel.com>
Subject: Re: [PATCH v10 48/50] KVM: SEV: Provide support for
 SNP_GUEST_REQUEST NAE event
Message-ID: <656f82b4b1972_45e012944e@dwillia2-xfh.jf.intel.com.notmuch>
References: <20231016132819.1002933-49-michael.roth@amd.com>
 <CAAH4kHb=hNH88poYw-fj+ewYgt8F-hseZcRuLDdvbgpSQ5FDZQ@mail.gmail.com>
 <ZS614OSoritrE1d2@google.com>
 <b9da2fed-b527-4242-a588-7fc3ee6c9070@amd.com>
 <ZS_iS4UOgBbssp7Z@google.com>
 <20231110220756.7hhiy36jc6jiu7nm@amd.com>
 <ZU6zGgvfhga0Oiob@google.com>
 <CAAH4kHYPAiS+_KKhb1=8q=OkS+XBsES8J3K_acJ_5YcNZPi=kA@mail.gmail.com>
 <656e6f0aa1c5_4568a29451@dwillia2-xfh.jf.intel.com.notmuch>
 <CAAH4kHb7cfMetpC=AYy=FjTTve6g0W8NZdeSwQ8uVxkqi2491Q@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAAH4kHb7cfMetpC=AYy=FjTTve6g0W8NZdeSwQ8uVxkqi2491Q@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?1yfMlUMOLIIrk59SQsDs835gSkScZiEOLnRTQUieyNjRTxqBfLnLxestWvYL?=
 =?us-ascii?Q?cRqzJHb/axSlDGd+xStLJWflfIYGn0B075qYi6mv2qHF7aPY7r0bReZeqRj/?=
 =?us-ascii?Q?+IWX9KBBHDZTV9900smx8ItaqqMm2VhdBTFakcP+H3ZLqwmvQLmv7rA0Ddfo?=
 =?us-ascii?Q?+PRn83+upF6N44GZpVaJHCOK/GSJwrnzANRDr/9Um+18Jh17gqfzQ+uwQKwc?=
 =?us-ascii?Q?YLhHOpE0pQcbv+xnxZ9IMOhV+HwQEgT+5eqQ19NOgXd2RrfNGeqYizvwTcRO?=
 =?us-ascii?Q?Y2ZC8TfMTS94y5hR+NfPMD6wKgGkInXZW8IusLXizH/MpKSxLJkI3Zqzhb0J?=
 =?us-ascii?Q?5DAmg14XP528o+NDff+3VYgWSDsY9H311y1TNhikfWvWCMrJNqZ0LCK7j0zp?=
 =?us-ascii?Q?f18WizWvtnIJOkqIF81FDuLsG+CULgb+hWWW6rEwUEdMNVd6/zK18qoHPoLb?=
 =?us-ascii?Q?EsL/3wTcmdvYHt4mdbCkBjrimsDTFhWZYXCDc3u3Vtj9vXa4PqoAH0B9POau?=
 =?us-ascii?Q?ZXHaU81H2dY3Nmdy818pRZ5IHaUbQA2kVdeJnbfLy+5flMimcvqTX7d9u1TX?=
 =?us-ascii?Q?FPSGnzeg8Mve2hq4wK57Oom02Ind0EyhBs8oB77aXF+rTULBdk72ZYBl9pfQ?=
 =?us-ascii?Q?zL8UieaiFF9lVXjhriZUb3EzuGkwas+KO0mIXlQ9kgmf7GVsIa0l933KNQre?=
 =?us-ascii?Q?0sH5aREGaG2HfG2lpS9aJPRD2DOk5mhe0akszxassZsrBeDbx1g1fmrC0heH?=
 =?us-ascii?Q?ZJpHqHVU1if4JLOMfgjCJqWaugx4Aq/Hq934H2W+TNMewU0ZFx+2jMCegU8e?=
 =?us-ascii?Q?3CrDk0vdvKLQ2rN9XEg55X2Zs92mFBm1ntqcT68uN+ezMY+pIhsYzywt3eUj?=
 =?us-ascii?Q?WUw3eJL/p0G5v4pgCt/dRGu3gqdXYEeprXdYYwQSf/i2vwteLcLP1/AVmtsO?=
 =?us-ascii?Q?56HHMI3WbacqMGVxc5awd7mqI/b1TrzZjdh30aDYI3s++7O+ejwnmBYAhh6R?=
 =?us-ascii?Q?+r6q2tlfzZNdi8jM96+zFI027z9Uolp+I+9Ij0usWX49aqap09RlwJJ2VZ+d?=
 =?us-ascii?Q?NALdGc6Hhncb1e2Q7O1ZTW92iGIuUQ9gSCTvHSNFLwdJkHR0jyGSgeaPvnIN?=
 =?us-ascii?Q?cdr4RWahznsQpC432D7Bz75CszMy0kMWGXKSS9qj6C0o3pjewF3LmzFU66sS?=
 =?us-ascii?Q?WFWpEV+uVTel8/khj8kabV7bzwSLa11KhIGIYaF1G4Fom1lLbd0QpX8lXyxd?=
 =?us-ascii?Q?mGr4GAyBfoCMe8wJ0Exzh+GVF+IKG6InNZ8oCwEVcokzDCjOS6qxwFZjiBDp?=
 =?us-ascii?Q?oUT0qD7yUuwjr1Wvixi8pcH92uxXseb5zfUs3wXVSotUJW2UAIfpZb+9TCoV?=
 =?us-ascii?Q?Bml8HNwkWbENr/D43gH87SxIDFjMEBKt3XmF2cEfc8NKRoUiZch5TNR84JhX?=
 =?us-ascii?Q?cJY1PbZbADIJJsnqUtZ9pu5WuJv5egeTdd/ywAtUemaTs6HbdOSg4fA6vepk?=
 =?us-ascii?Q?IilZ27naokqvNv5aam0agVnW3e6duudbm/oUVPbaJPXhYDo1MfFBb+KIezk+?=
 =?us-ascii?Q?b1krH53FoQrIoroxRQZbZxPAUESoo9r9mPztBtXcUJeKTkHPMXlCnktPGT51?=
 =?us-ascii?Q?pw=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 9ce8f1d6-995f-4034-8a21-08dbf5cdb0d2
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2023 20:06:39.1311
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 7Te2ssBNr66jDI3RtjUytIKQmv04SysmLXqQqWLIQ42sT6/eGSMVDuM53R551BFC1CRlaR11/1YkGi19q/jtusdkGw5PxR7SFbz6TVzv8Fg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5167
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Tue, 05 Dec 2023 12:07:07 -0800 (PST)

[ 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'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.

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?

> 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.

> 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.