Message-ID: <64dbc039c08b0_28996294ce@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Date:   Tue, 15 Aug 2023 11:13:13 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Peter Gonda <pgonda@...gle.com>,
        Dan Williams <dan.j.williams@...el.com>
CC:     Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>,
        <linux-coco@...ts.linux.dev>,
        Brijesh Singh <brijesh.singh@....com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Borislav Petkov <bp@...en8.de>,
        "Dionna Amalie Glaze" <dionnaglaze@...gle.com>,
        Samuel Ortiz <sameo@...osinc.com>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        <x86@...nel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/5] tsm: Attestation Report ABI

Peter Gonda wrote:
> On Mon, Aug 14, 2023 at 11:12 AM Dan Williams <dan.j.williams@...el.com> wrote:
> >
> > Jeremi Piotrowski wrote:
> > > On 8/14/2023 9:43 AM, Dan Williams wrote:
> > > > Changes since v1:
> > > > - Switch from Keyring to sysfs (James)
> > > >
> > > > An attestation report is signed evidence of how a Trusted Virtual
> > > > Machine (TVM) was launched and its current state. A verifying party uses
> > > > the report to make judgements of the confidentiality and integrity of
> > > > that execution environment. Upon successful attestation the verifying
> > > > party may, for example, proceed to deploy secrets to the TVM to carry
> > > > out a workload. Multiple confidential computing platforms share this
> > > > similar flow.
> > > >
> > > > The approach of adding adding new char devs and new ioctls, for what
> > > > amounts to the same logical functionality with minor formatting
> > > > differences across vendors [1], is untenable. Common concepts and the
> > > > community benefit from common infrastructure.
> > > >
> > > > Use sysfs for this facility for maintainability compared to ioctl(). The
> > > > expectation is that this interface is a boot time, configure once, get
> > > > report, and done flow. I.e. not something that receives ongoing
> > > > transactions at runtime. However, runtime retrieval is not precluded and
> > > > a mechanism to detect potential configuration conflicts from
> > > > multiple-threads using this interface is included.
> > > >
> > >
> > > I wanted to speak up to say that this does not align with the needs we have
> > > in the Confidential Containers project. We want to be able to perform attestation
> > > not just once during boot but during the lifecycle of the confidential VM. We
> > > may need to fetch a fresh attestation report from a trusted agent but also from
> > > arbitrary applications running in containers.
> > >
> > > The trusted agent might need attestation when launching a new container from an
> > > encrypted container image or when a new secret is being added to the VM - both
> > > of these events may happen at any time (also when containerized applications
> > > are already executing).
> > >
> > > Container applications have their own uses for attestation, such as when they need
> > > to fetch keys required to decrypt payloads. We also have things like performing
> > > attestation when establishing a TLS or ssh connection to provide an attested e2e
> > > encrypted communication channel.
> >
> > ...and you expect that the boot time attestation becomes invalidated
> > later at run time such that ongoing round trips to the TSM are needed? I
> > am looking at "Table 21. ATTESTATION_REPORT Structure" for example and
> > not seeing data there that changes from one request to the next. Runtime
> > validation likely looks more like the vTPM use case with PCRs. That will
> > leverage the existing / common TPM ABI.
> 
> I thought we were dropping the TSM acronym as requested by Jarkko?

I read that in the context of the key-type name. The key-type proposal
was dropped.

> Why do we need to be so prescriptive about "boot time" vs "runtime"
> attestations? A user may wish to attest to several requests as Jeremi
> notes. And why should users be forced into using a vTPM interface if
> their usecase doesn't require all the features and complexity of a
> vTPM?

When I said "like vTPM" I did not mean to infer "only vTPM". There are
three scenarios base attestation reports, attestation reports with
runtime measurement values, and vTPM. This patchset is only about the
first scenario.

RTMRs have similarities with PCRs, does that mean they need to be
intergrated behind the existing TPM ABI or deserve something new? That
is a question that the RTMR enabling effort will need to answer.

> Some users may prefer less overall code within their Trusted
> Computer Base (TCB) and a TPM emulate is a significant code base.

Yes.

> It seems like you are just reading the SNP spec,

Nope, fully aware of the TDX spec. This patchset is around wrapping the
existing sev-guest capability with a shared ABI for the TDX equivalen.

> if you read the TDX
> spec you'll see there are RTMRs which can be extended with new data.
> This leads to a different data in the attestation. Similar there are
> REMs in the ARM CCA spec.

Again, RTMRs are not part of this current proposal.

Powered by blists - more mailing lists