linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-coco@lists.linux.dev,
	Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	Dionna Amalie Glaze <dionnaglaze@google.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Peter Gonda <pgonda@google.com>,
	Samuel Ortiz <sameo@rivosinc.com>,
	peterz@infradead.org, x86@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/5] tsm: Introduce a shared ABI for attestation reports
Date: Mon, 14 Aug 2023 20:43:29 +0200	[thread overview]
Message-ID: <2023081454-mortify-unopened-5b71@gregkh> (raw)
In-Reply-To: <64da59b9924d2_2138e2947f@dwillia2-xfh.jf.intel.com.notmuch>

On Mon, Aug 14, 2023 at 09:43:37AM -0700, Dan Williams wrote:
> Greg Kroah-Hartman wrote:
> > On Mon, Aug 14, 2023 at 12:43:21AM -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, COVE if not
> > > more, is to define a sysfs interface to retrieve the TSM-specific blob.
> > > 
> > >     echo $hex_encoded_userdata_plus_nonce > /sys/class/tsm/tsm0/inhex
> > >     hexdump /sys/class/tsm/tsm0/outblob
> > 
> > Why is one way a hex-encode file, that the kernel has to parse, and the
> > other not?  Binary sysfs files should be "pass through" if at all
> > possible, why not make them both binary and not mess with hex at all?
> > That keeps the kernel simpler, and if userspace wants the hex format,
> > they can provide it much easier (with less potential parsing errors).
> 
> I can do that. The concern was the contract around what to do with
> partial writes since binary attributes allow writing the middle of the
> buffer. So either the attribute needs to enforce that @offset is always
> zero, or that the unwritten portion of the buffer is zeroed. I will go
> with just enforcing offset=zero writes.

Enforcing that sounds sane, thanks.

greg k-h

  reply	other threads:[~2023-08-14 18:43 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-14  7:43 [PATCH v2 0/5] tsm: Attestation Report ABI Dan Williams
2023-08-14  7:43 ` [PATCH v2 1/5] virt: coco: Add a coco/Makefile and coco/Kconfig Dan Williams
2023-08-14  7:43 ` [PATCH v2 2/5] tsm: Introduce a shared ABI for attestation reports Dan Williams
2023-08-14  8:24   ` Jeremi Piotrowski
2023-08-14 16:21     ` Dan Williams
2023-08-14 15:38   ` Greg Kroah-Hartman
2023-08-14 16:43     ` Dan Williams
2023-08-14 18:43       ` Greg Kroah-Hartman [this message]
2023-08-15 19:51   ` Tom Lendacky
2023-08-16 14:44   ` Tom Lendacky
2023-08-16 15:12     ` Dan Williams
2023-08-22  7:29   ` Roy Hopkins
2023-08-23 13:49   ` Samuel Ortiz
2023-08-28 10:46     ` Dr. Greg
2023-08-14  7:43 ` [PATCH v2 3/5] virt: sevguest: Prep for kernel internal {get, get_ext}_report() Dan Williams
2023-08-14 16:58   ` Dionna Amalie Glaze
2023-08-14 23:24     ` Dan Williams
2023-08-15 20:11       ` Tom Lendacky
2023-08-15 21:03         ` Dan Williams
2023-08-16 19:38           ` Dionna Amalie Glaze
2023-08-15 20:20   ` Tom Lendacky
2023-08-15 21:37     ` Dan Williams
2023-08-14  7:43 ` [PATCH v2 4/5] mm/slab: Add __free() support for kvfree Dan Williams
2023-08-14 15:31   ` Greg Kroah-Hartman
2023-08-14 16:17     ` Peter Zijlstra
2023-08-14 18:44       ` Greg Kroah-Hartman
2023-08-14 18:45         ` Greg Kroah-Hartman
2024-01-04  6:57       ` Lukas Wunner
2024-01-04 18:29         ` Dan Williams
2023-08-14  7:43 ` [PATCH v2 5/5] virt: sevguest: Add TSM_REPORTS support for SNP_{GET, GET_EXT}_REPORT Dan Williams
2023-08-14  8:30   ` Jeremi Piotrowski
2023-08-14 16:22     ` Dan Williams
2023-08-14 11:21   ` Peter Zijlstra
2023-08-14 16:25     ` Dan Williams
2023-08-14 16:48       ` Peter Zijlstra
2023-08-14 22:15         ` Peter Zijlstra
2023-08-15  8:37           ` Peter Zijlstra
2023-08-15 20:50   ` Tom Lendacky
2023-08-15 21:40     ` Dan Williams
2023-08-14  9:04 ` [PATCH v2 0/5] tsm: Attestation Report ABI Jeremi Piotrowski
2023-08-14 17:12   ` Dan Williams
2023-08-15 14:27     ` Peter Gonda
2023-08-15 17:16       ` Dionna Amalie Glaze
2023-08-15 21:13         ` Dan Williams
2023-08-15 18:13       ` Dan Williams
2023-08-16  9:42     ` Jeremi Piotrowski
2023-08-23 11:21   ` Dr. Greg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2023081454-mortify-unopened-5b71@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=dan.j.williams@intel.com \
    --cc=dionnaglaze@google.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=pgonda@google.com \
    --cc=sameo@rivosinc.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).