linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Christophe de Dinechin <cdupontd@redhat.com>
Cc: Cedric Xing <cedric.xing@intel.com>,
	"dan. j. williams" <dan.j.williams@intel.com>,
	Samuel Ortiz <sameo@rivosinc.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Lukas Wunner <lukas@wunner.de>,
	Dionna Amalie Glaze <dionnaglaze@google.com>,
	Qinkun Bao <qinkun@google.com>,
	Mikko Ylinen <mikko.ylinen@linux.intel.com>,
	Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	linux-coco <linux-coco@lists.linux.dev>,
	suzuki.poulose@arm.com, sami.mujawar@arm.com
Subject: Re: [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs
Date: Thu, 12 Sep 2024 12:02:28 +0100	[thread overview]
Message-ID: <20240912110228.GA28024@myrica> (raw)
In-Reply-To: <B3201E6B-D479-45EE-9E44-868042E04E5B@redhat.com>

On Thu, Sep 12, 2024 at 12:03:05PM +0200, Christophe de Dinechin wrote:
> It’s nice to have a similar structure between ARM and x86, but how does
> user space know what each register holds? For example, say that I want
> a digest of the initial VM state, of the boot configuration, of the
> command line, or of the firmware, where do I get that? When using a TPM,
> there are conventions on which PCR stores which particular piece of
> information.

It's early days for Arm and this is still something we need to formalize.
The initial VM state always goes in the RIM (~MRTD) and REM[0-3] (~RTMR)
contain runtime measurements. TDX already defined a correspondence between
PCR and RTMR in UEFI:

https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust-domain-extension

  TPM PCR Index | TDX-measurement register
   ---------------------------------------
  0             |   MRTD
  1, 7          |   RTMR[0]
  2~6           |   RTMR[1]
  8~15          |   RTMR[2]


It would make sense for Arm to follow the same convention. This way, FW
knows where to put new measurements. And extending this mapping, remaining
PCRs could for example all go in RTMR[3].

Verifiers and other consumers don't need to know any of these conventions,
they can just read the event log to know where each component was measured.

> Is the idea to defer that to user space, or should we also have some
> symlinks exposing this or that specific register when it exists under
> a common, platform-agnostic name? e.g. on ARM you would have
> 
> /sys/kernel/config/tsm/initial_vm_state -> ./rim
> 
> It looks to me like this could simplify the writing of user-space
> attestation agents, for example. But then, maybe I’m too optimistic
> and such agents would always be platform-dependent anyway.

I agree, it may be useful to have a single platform-agnostic link for
generic applications that need to extend measurements. For example one
RTMR could be picked by the TSM driver:

/sys/kernel/config/tsm/extend_measurement -> ./rtmr3

I'm not sure it's useful to provide a shortcut to initial_vm_state
however, because as I understand it an attestation agent just wants to
bundle all digests and send them to a verifier, something already provided
in a platform-agnostic way by configfs-tsm report/

Thanks,
Jean

> 
> One data point is that about one year ago, CoCo has already split the
> platform dependencies away in their attestation stack, at the time
> mostly to cover differences between AMD and Intel.
> 
> > 
> > Thanks,
> > Jean
> > 
> > 
> 
> Cheers,
> Christophe de Dinechin (https://c3d.github.io)
> Freedom Covenant (https://github.com/c3d/freedom-covenant)
> Theory of Incomplete Measurements (https://c3d.github.io/TIM)
> 

  reply	other threads:[~2024-09-12 11:02 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-08  4:56 [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs Cedric Xing
2024-09-08  4:56 ` [PATCH RFC 1/3] tsm: Add TVM Measurement Register Support Cedric Xing
2024-09-08  4:56 ` [PATCH RFC 2/3] tsm: Add RTMR event logging Cedric Xing
2024-09-08  4:56 ` [PATCH RFC 3/3] tsm: Add TVM Measurement Sample Code Cedric Xing
2024-09-09 15:14   ` Jeff Johnson
2024-09-09 15:20     ` Xing, Cedric
2024-09-12 12:28   ` James Bottomley
2024-09-14 16:36     ` Xing, Cedric
2024-09-14 17:10       ` James Bottomley
2024-09-15  4:53         ` Xing, Cedric
2024-10-24 17:21         ` Mikko Ylinen
2024-09-08 17:37 ` [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs Alexander Graf
2024-09-09 14:55   ` Xing, Cedric
2024-09-10  7:47     ` Alexander Graf
2024-09-10 18:07       ` Xing, Cedric
2024-09-10 17:09 ` Jean-Philippe Brucker
2024-09-11  4:01   ` Xing, Cedric
2024-09-11  6:56     ` Alexander Graf
2024-09-12 15:43       ` Xing, Cedric
2024-09-13  9:43         ` Alexander Graf
2024-09-11 12:06     ` James Bottomley
2024-09-11 13:46       ` Qinkun Bao
2024-09-11 14:10         ` James Bottomley
2024-09-12  3:23           ` Xing, Cedric
2024-09-12 12:15             ` James Bottomley
2024-09-12 19:00               ` Xing, Cedric
2024-09-13 12:55                 ` James Bottomley
2024-09-15  4:31                   ` Xing, Cedric
2024-09-13 12:58                 ` James Bottomley
2024-09-15  5:14                   ` Xing, Cedric
2024-09-11 23:29       ` Dan Williams
2024-09-11 23:36     ` Dan Williams
2024-09-12  9:25     ` Jean-Philippe Brucker
2024-09-12 10:03   ` Christophe de Dinechin
2024-09-12 11:02     ` Jean-Philippe Brucker [this message]
2024-09-13 19:42     ` Xing, Cedric

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=20240912110228.GA28024@myrica \
    --to=jean-philippe@linaro.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=cdupontd@redhat.com \
    --cc=cedric.xing@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dionnaglaze@google.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mikko.ylinen@linux.intel.com \
    --cc=qinkun@google.com \
    --cc=sameo@rivosinc.com \
    --cc=sami.mujawar@arm.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=suzuki.poulose@arm.com \
    /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).