linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Cedric Xing <cedric.xing@intel.com>
Cc: Dan 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@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: Tue, 10 Sep 2024 18:09:59 +0100	[thread overview]
Message-ID: <20240910170959.GA213064@myrica> (raw)
In-Reply-To: <20240907-tsm-rtmr-v1-0-12fc4d43d4e7@intel.com>

Hi Cedric,

On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote:
> Patch 2 introduces event log support for RTMRs, addressing the fact that the
> standalone values of RTMRs, which represent the cumulative digests of
> sequential events, are not fully informative on their own.

Would each event_log include the events that firmware wrote before Linux?
I'm wondering how this coexists with /sys/firmware/acpi/tables/data/CCEL.
Maybe something like: CCEL only contains pre-Linux events. The TSM driver
parses CCEL (using a format specific to the arch, for example TCG2),
separates the events by MR and produces event_log files in
/sys/kernel/tsm/, possibly in a different format like CEL-TLV. Is that
what you envision for TDX?

I ask because I've been looking into this interface for Arm CCA, and
having unified event logs available somewhere in /sys/kernel/confg/tsm
would be very convenient for users (avoids having to parse and convert
different /sys/firmware interfaces along with Linux event logs). I would
have put a single event_log in /sys/kernel/config/tsm/report/ but
splitting it by MR should work too.

As Alex I believe we need more similarity between the interfaces of static
and runtime measurements, because verifiers may benefit from an event log
of static measurements. For example Arm could have a configuration like
this:

  struct tsm_measurement_register arm_cca_mrs[] = {
	{ MR_(rim) | TSM_MR_F_R | TSM_MR_F_LOG, HA },
  	{ MR_(rem0) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
  	...
  	{ MR_(rem3) | TSM_MR_F_R | TSM_MR_F_X | TSM_MR_F_LOG, HA },
  };

Here rim is a static measurement of the initial VM state, impossible to
extend but could have an event log. rem0-3 are runtime measurements,
extensible by firmware and then Linux. None of the digests can be written
directly, only extended and read with calls to the upper layer. The tree
would be:

  /sys/kernel/config/tsm/
  ├── rim
  │   ├── digest
  │   ├── event_log
  │   └── hash_algo
  ├── rem0
  │   ├── digest
  │   ├── append_event
  │   ├── event_log
  │   └── hash_algo
  ... 
  ├── rem3
  │   ├── digest
  │   ├── append_event
  │   ├── event_log
  │   └── hash_algo
  └── report/$name
      ├── inblob
      └── outblob

Thanks,
Jean


  parent reply	other threads:[~2024-09-10 17:09 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 [this message]
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
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=20240910170959.GA213064@myrica \
    --to=jean-philippe@linaro.org \
    --cc=James.Bottomley@hansenpartnership.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).