Message-ID: <65a979f25c180_37ad294b2@dwillia2-xfh.jf.intel.com.notmuch>
Date: Thu, 18 Jan 2024 11:20:18 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Dionna Amalie Glaze <dionnaglaze@...gle.com>, <biao.lu@...el.com>
CC: <sameo@...osinc.com>, <dan.j.williams@...el.com>,
	<linux-coco@...ts.linux.dev>, <linux-kernel@...r.kernel.org>, Joerg Roedel
	<jroedel@...e.de>
Subject: Re: [RFC PATCH v1 0/4] tsm: Runtime measurement registers ABI

Dionna Amalie Glaze wrote:
> On Wed, Jan 17, 2024 at 7:36 PM <biao.lu@...el.com> wrote:
> >
> > Samuel Ortiz wrote:
> > > Some confidential computing architectures (Intel TDX, ARM CCA, RISC-V
> > > CoVE) provide their guests with a set of measurements registers that can
> > > be extended at runtime, i.e. after the initial, host-initiated
> > > measurements of the TVM are finalized. Those runtime measurement
> > > registers (RTMR) are isolated from the host accessible ones but TSMs
> > > include them in their signed attestation reports.
> > >
> > > All architectures supporting RTMRs expose a similar interface to their
> > > TVMs: An extension command/call that takes a measurement value and an
> > > RTMR index to extend it with, and a readback command for reading an RTMR
> > > value back (taking an RTMR index as an argument as well). This patch series
> > > builds an architecture agnostic, configfs-based ABI for userspace to extend
> > > and read RTMR values back. It extends the current TSM ops structure and
> > > each confidential computing architecture can implement this extension to
> > > provide RTMR support.
> >
> > Hi, Samuel
> > The ABI does not include eventlog, but eventlog is usually used with RTMR.
> > What do you think about how to implement eventlog?
> >
> >
> 
> I had the same question and deleted my reply. The event log in TPM is
> made available in sysfs only up to the point that control transitions
> to user space. After that, all extensions to PCRs have to be logged by
> user space with whatever chosen workload event log representation. I
> imagine the same is true for RTMRs.
> 
> What this patch series doesn't take into account is how RTMRs might
> not be represented in the hardware attestation, but rather would be in
> a supervisor service whose integrity is chained from hardware
> attestation. In the configfs-tsm model, tsm/report with its single
> provider requirement will not be able to interface with the SVSM
> attestation protocol /and/ the AMD hardware protocol. That may as well
> be okay, but that's a choice folks need to be aware of. There's still
> the issue of attesting a single service vs attesting all services in
> the SVSM. I imagine single service attestation will have to be
> abandoned.
> 
> In SVSM, a vTPM is a service that an updated linux driver will be able
> to get a quote from, and the same AMD SEV-SNP attestation report TSM
> provider would still be present, but if we want a simpler RTMR
> service, then we're in a little pickle with this design.

There is a good chance I am misunderstanding the concern, but I would
say yes, the vTPM that would be layered on top of RTMRs is independent
of the SVSM vTPM effort. For an architecture without RTMRs, vTPM via
SVSM is likely the only choice, and for architectures with RTMRs an SVSM
indepdendent vTPM is possible. For the kernel it already has a
vtpm_proxy driver that could be put to use here, and that would be
independent of the eventual SVSM vTPM driver.

I am using "SVSM" above with the model of a layer providing services to
an unenlightened TVM in mind. In contrast, this RTMR model requires some
TVM enlightenment to setup vtpm_proxy on top of this cross-architecture
building block.

Powered by blists - more mailing lists