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

[Christophe de Dinechin]

> On 10 Sep 2024, at 19:09, Jean-Philippe Brucker <jean-philippe@xxxxxxxxxx> wrote:
> 
> 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

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.

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.

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)