Received-SPF: pass (google.com: domain of linux-kernel+bounces-30433-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <20240114223532.290550-1-sameo@rivosinc.com> <20240118033515.2293149-1-biao.lu@intel.com>
In-Reply-To: <20240118033515.2293149-1-biao.lu@intel.com>
From: Dionna Amalie Glaze <dionnaglaze@google.com>
Date: Thu, 18 Jan 2024 09:42:50 -0800
Message-ID: <CAAH4kHb9-7p0z2xgmofiCVkOUgXdkJz89qLPc1DuG0F_Wf4-Tg@mail.gmail.com>
Subject: Re: [RFC PATCH v1 0/4] tsm: Runtime measurement registers ABI
To: biao.lu@intel.com
Cc: sameo@rivosinc.com, dan.j.williams@intel.com, linux-coco@lists.linux.dev, 
	linux-kernel@vger.kernel.org, Joerg Roedel <jroedel@suse.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 17, 2024 at 7:36=E2=80=AFPM <biao.lu@intel.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 ca=
n
> > 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 RTM=
R
> > value back (taking an RTMR index as an argument as well). This patch se=
ries
> > builds an architecture agnostic, configfs-based ABI for userspace to ex=
tend
> > and read RTMR values back. It extends the current TSM ops structure and
> > each confidential computing architecture can implement this extension t=
o
> > 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.

--=20
-Dionna Glaze, PhD (she/her)