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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240912110228.GA28024@myrica>
Date: Thu, 12 Sep 2024 12:02:28 +0100
From: Jean-Philippe Brucker <jean-philippe@...aro.org>
To: Christophe de Dinechin <cdupontd@...hat.com>
Cc: Cedric Xing <cedric.xing@...el.com>,
	"dan. j. 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 <linux-coco@...ts.linux.dev>, suzuki.poulose@....com,
	sami.mujawar@....com
Subject: Re: [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs

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)
>