linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Claudio Siqueira de Carvalho <cclaudio@ibm.com>,
	 "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	"svsm-devel@coconut-svsm.dev" <svsm-devel@coconut-svsm.dev>
Cc: "joro@8bytes.org" <joro@8bytes.org>
Subject: Re: SVSM Development Call - June 12th, 2024
Date: Wed, 12 Jun 2024 08:20:03 -0400	[thread overview]
Message-ID: <8bce2394bc209f1bae708d51c8a233850db699bb.camel@HansenPartnership.com> (raw)
In-Reply-To: <18df8b3afe39075dd9ab1211d17db83731d39cdf.camel@ibm.com>

On Tue, 2024-06-11 at 20:46 +0000, Claudio Siqueira de Carvalho wrote:
> Hi,
> 
> I would like to add two topics to the SVSM meeting agenda:
> 
> - What does TPM locality[1] mean for the SVSM vTPM?

Well, unlike the physical TPM, which is locked to locality zero unless
you do a dynamic launch, the SVSM vTPM protocol supports any locality
(in that way it's the same as a vTPM attached to a VM).  This would
allow us to operate userspace and the kernel at different localities
meaning there could be key sealing policies that won't allow a key to
unseal in the userspace locality (i.e. kernel only).  Adding
functionality like this doesn't require the SVSM to police localities
(the kernel does it).

Policing localities is more problematic for the SVSM.  It means that
the SVSM must ensure that a particular locality request comes from a
particular trust level.  For instance in a dynamic launch, the TIS TPM
polices localities by replicating register access pages (one for each
locality) and then the chipset blocks access to some of them as the
boot continues.

The problem for the SVSM-vTPM is that it's hard to employ this type of
access sealing mechanism without an additional command and enlightening
all the OS components to use it, so unless there's a reason to reserve
a locality exclusively for the SVSM (say to unseal a provided secret
only for it) 

> - Is there any SVSM boot event that we want to record in the TPM
> PCRs/Event log?
> E.g. a SVSM configuration, the OVMF hash, etc

OVMF records all the mandatory TCG measured boot events, including its
own measurement.  This, unfortunately, includes the static core root of
trust (SCRT) measurement, which is supposed to be the first entry.  We
could still add preceding SVSM measurements, but this would be a
technical spec violation.

Probably what needs to happen is that the SVSM-vTPM should be
responsible for the SCRT Measurement and OVMF should detect the
presence of the SVSM and assume it's been done.  That would give us
scope for adding the SVSM configuration to the SCRT measurement.

Regards,

James


      parent reply	other threads:[~2024-06-12 12:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-11 20:46 SVSM Development Call - June 12th, 2024 Claudio Siqueira de Carvalho
2024-06-12 10:00 ` [svsm-devel] " Stefano Garzarella
2024-06-12 10:22   ` Yao, Jiewen
2024-06-12 12:29   ` James Bottomley
2024-06-12 12:20 ` James Bottomley [this message]

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=8bce2394bc209f1bae708d51c8a233850db699bb.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=cclaudio@ibm.com \
    --cc=joro@8bytes.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=svsm-devel@coconut-svsm.dev \
    /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).