From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF7A979F7 for ; Wed, 30 Aug 2023 20:45:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D46FEC433C7; Wed, 30 Aug 2023 20:45:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1693428355; bh=TqT9Cfnwh+ygT7+Q36jzRz6qPPhxjFw4O+Y4jAuDhY4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=W3DzMfdkwsUo7rS3Py9nPQPIMP4TmsOeS9JfFgHlUxMFHPK1t+zdZdoeklydPnbRM Eu3KuNS0QkC2zfvvZOlsPBOun1q/lLVrGTQOPnetsemi2nf4Lvl2869QtfpBRW4Esi FBqyyKH4T/41WGAdBbqEmOQXW+/N7+RAfxOPiu8U= Date: Wed, 30 Aug 2023 22:45:52 +0200 From: Greg Kroah-Hartman To: Dan Williams Cc: linux-coco@lists.linux.dev, Kuppuswamy Sathyanarayanan , Dionna Amalie Glaze , James Bottomley , Peter Gonda , Samuel Ortiz , peterz@infradead.org, linux-kernel@vger.kernel.org, tglx@linutronix.de Subject: Re: [PATCH v3 2/5] configfs-tsm: Introduce a shared ABI for attestation reports Message-ID: <2023083029-wackiness-lilac-39dd@gregkh> References: <169342399185.3934343.3035845348326944519.stgit@dwillia2-xfh.jf.intel.com> <169342400469.3934343.12316161608372095860.stgit@dwillia2-xfh.jf.intel.com> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <169342400469.3934343.12316161608372095860.stgit@dwillia2-xfh.jf.intel.com> On Wed, Aug 30, 2023 at 12:33:24PM -0700, Dan Williams wrote: > One of the common operations of a TSM (Trusted Security Module) is to > provide a way for a TVM (confidential computing guest execution > environment) to take a measurement of its launch state, sign it and > submit it to a verifying party. Upon successful attestation that > verifies the integrity of the TVM additional secrets may be deployed. > The concept is common across TSMs, but the implementations are > unfortunately vendor specific. While the industry grapples with a common > definition of this attestation format [1], Linux need not make this > problem worse by defining a new ABI per TSM that wants to perform a > similar operation. The current momentum has been to invent new ioctl-ABI > per TSM per function which at best is an abdication of the kernel's > responsibility to make common infrastructure concepts share common ABI. > > The proposal, targeted to conceptually work with TDX, SEV-SNP, COVE if > not more, is to define a configfs interface to retrieve the TSM-specific > blob. > > report=/sys/kernel/config/tsm/report/report0 > mkdir $report > dd if=binary_userdata_plus_nonce > $report/inblob > hexdump $report/outblob > > This approach later allows for the standardization of the attestation > blob format without needing to invent a new ABI. Once standardization > happens the standard format can be emitted by $report/outblob and > indicated by $report/provider, or a new attribute like > "$report/tcg_coco_report" can emit the standard format alongside the > vendor format. > > Review of previous iterations of this interface identified that there is > a need to scale report generation for multiple container environments > [2]. Configfs enables a model where each container can bind mount one or > more report generation item instances. Still, within a container only a > single thread can be manipulating a given configuration instance at a > time. A 'generation' count is provided to detect conflicts between > multiple threads racing to configure a report instance. > > The SEV-SNP concepts of "extended reports" and "privilege levels" are > optionally enabled by selecting 'tsm_report_ext_type' at register_tsm() > time. The expectation is that those concepts are generic enough that > they may be adopted by other TSM implementations. In other words, > configfs-tsm aims to address a superset of TSM specific functionality > with a common ABI where attributes may appear, or not appear, based on the set > of concepts the implementation supports. > > Link: http://lore.kernel.org/r/64961c3baf8ce_142af829436@dwillia2-xfh.jf.intel.com.notmuch [1] > Link: http://lore.kernel.org/r/57f3a05e-8fcd-4656-beea-56bb8365ae64@linux.microsoft.com [2] > Cc: Kuppuswamy Sathyanarayanan > Cc: Dionna Amalie Glaze > Cc: James Bottomley > Cc: Peter Gonda > Cc: Greg Kroah-Hartman > Cc: Samuel Ortiz > Signed-off-by: Dan Williams > --- > Documentation/ABI/testing/configfs-tsm | 68 ++++++ Nice, I like the use of configfs here. One very tiny naming nit, feel free to ignore if you don't want to change it: > +int register_tsm(const struct tsm_ops *ops, void *priv, > + const struct config_item_type *type); > +int unregister_tsm(const struct tsm_ops *ops); Usually it's "noun_verb" for stuff that you export to the global namespace these days. So perhaps tsm_register() and tsm_unregister()? Either way, it's your call: Acked-by: Greg Kroah-Hartman