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

[Xing, Cedric]

On 9/12/2024 5:03 AM, Christophe de Dinechin wrote:
> > 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
> On the surface, a convention + symlinks could be a solution to the problem.

But if we dig deeper, a conventions will be difficult to establish 
because different users/tenants/applications have different needs in 
passing configurations/policies (or additional whatever). A more generic 
model is to allow upper layer software to specify arbitrary number of 
measurements in the form of name/value pairs. For example, say `rim` is 
the only static MR on Arm but the tenant wants to pass in a policy file 
along with the tenant's public key. We could put the following 2 lines 
into rim's log (more like a manifest because the MR is static):

	kernel.org/tsm/static_mr mr_policy <policy digest>
	kernel.org/tsm/static_mr mr_pubkey <public key digest>

Then, assuming Arm CCA guest driver also understands the log format 
above, it would create 2 virtual/pseudo-MRs, namely `mr_policy` and 
`mr_pubkey`, to expose those digests to applications.

Then say, if the tenant wants the same application to run on Intel TDX, 
whose MRTD doesn't support the same semantics as rim, MROWNERCONFIG 
could be used instead - the same log entries but for MROWNERCONFIG this 
time. The TDX guest would then create the same `mr_policy` and 
`mr_pubkey` for those same applications to consume. Please note that 
those applications are CC arch agnostic (at source level).

During attestation/verification, the verifier is supposed to consist of 
a buttom (CC arch specific) layer and a top (CC arch agnostic) layer. 
The bottom would verify the integrity of the log using different MRs 
(rim on Arm CCA or MROWNERCONFIG on Intel TDX), then the top layer would 
extract and verify `mr_policy`/`mr_pubkey` against the reference values 
set forth by the tenant.

> 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 believe portable (CC arch agnostic) applications can be done, but 
there's still some way to go.

-Cedric