[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2023083029-wackiness-lilac-39dd@gregkh>
Date: Wed, 30 Aug 2023 22:45:52 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Dan Williams <dan.j.williams@...el.com>
Cc: linux-coco@...ts.linux.dev,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
Dionna Amalie Glaze <dionnaglaze@...gle.com>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Peter Gonda <pgonda@...gle.com>,
Samuel Ortiz <sameo@...osinc.com>, peterz@...radead.org,
linux-kernel@...r.kernel.org, tglx@...utronix.de
Subject: Re: [PATCH v3 2/5] configfs-tsm: Introduce a shared ABI for
attestation reports
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 <sathyanarayanan.kuppuswamy@...ux.intel.com>
> Cc: Dionna Amalie Glaze <dionnaglaze@...gle.com>
> Cc: James Bottomley <James.Bottomley@...senPartnership.com>
> Cc: Peter Gonda <pgonda@...gle.com>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Cc: Samuel Ortiz <sameo@...osinc.com>
> Signed-off-by: Dan Williams <dan.j.williams@...el.com>
> ---
> 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 <gregkh@...uxfoundation.org>
Powered by blists - more mailing lists