linux-kernel - Re: [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240910170959.GA213064@myrica>
Date: Tue, 10 Sep 2024 18:09:59 +0100
From: Jean-Philippe Brucker <jean-philippe@...aro.org>
To: Cedric Xing <cedric.xing@...el.com>
Cc: Dan Williams <dan.j.williams@...el.com>,
	Samuel Ortiz <sameo@...osinc.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Lukas Wunner <lukas@...ner.de>,
	Dionna Amalie Glaze <dionnaglaze@...gle.com>,
	Qinkun Bao <qinkun@...gle.com>,
	Mikko Ylinen <mikko.ylinen@...ux.intel.com>,
	Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>,
	linux-kernel@...r.kernel.org, linux-coco@...ts.linux.dev,
	suzuki.poulose@....com, sami.mujawar@....com
Subject: Re: [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs

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