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.

The keyring@ list is dropped on this posting since a new key-type is no
longer being pursued.

Link: http://lore.kernel.org/r/cover.1684048511.git.sathyanarayanan.kuppuswamy@linux.intel.com

---

Dan Williams (5):
      virt: coco: Add a coco/Makefile and coco/Kconfig
      tsm: Introduce a shared ABI for attestation reports
      virt: sevguest: Prep for kernel internal {get,get_ext}_report()
      mm/slab: Add __free() support for kvfree
      virt: sevguest: Add TSM_REPORTS support for SNP_{GET,GET_EXT}_REPORT


 Documentation/ABI/testing/sysfs-class-tsm |   47 +++++
 MAINTAINERS                               |    8 +
 drivers/virt/Kconfig                      |    6 -
 drivers/virt/Makefile                     |    4 
 drivers/virt/coco/Kconfig                 |   13 +
 drivers/virt/coco/Makefile                |    8 +
 drivers/virt/coco/sev-guest/Kconfig       |    1 
 drivers/virt/coco/sev-guest/sev-guest.c   |  129 ++++++++++++-
 drivers/virt/coco/tdx-guest/Kconfig       |    1 
 drivers/virt/coco/tsm.c                   |  290 +++++++++++++++++++++++++++++
 include/linux/slab.h                      |    2 
 include/linux/tsm.h                       |   45 +++++
 12 files changed, 535 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-tsm
 create mode 100644 drivers/virt/coco/Kconfig
 create mode 100644 drivers/virt/coco/Makefile
 create mode 100644 drivers/virt/coco/tsm.c
 create mode 100644 include/linux/tsm.h

base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5

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.

I don't think sysfs is suitable for such concurrent transactions. Also if you think
about exposing the sysfs interface to an application in a container, this requires
bind mounting rw part of the sysfs tree into the mount namespace - not ideal.

Jeremi

> The keyring@ list is dropped on this posting since a new key-type is no
> longer being pursued.
> 
> Link: http://lore.kernel.org/r/cover.1684048511.git.sathyanarayanan.kuppuswamy@linux.intel.com
> 
> ---
> 
> Dan Williams (5):
>       virt: coco: Add a coco/Makefile and coco/Kconfig
>       tsm: Introduce a shared ABI for attestation reports
>       virt: sevguest: Prep for kernel internal {get,get_ext}_report()
>       mm/slab: Add __free() support for kvfree
>       virt: sevguest: Add TSM_REPORTS support for SNP_{GET,GET_EXT}_REPORT
> 
> 
>  Documentation/ABI/testing/sysfs-class-tsm |   47 +++++
>  MAINTAINERS                               |    8 +
>  drivers/virt/Kconfig                      |    6 -
>  drivers/virt/Makefile                     |    4 
>  drivers/virt/coco/Kconfig                 |   13 +
>  drivers/virt/coco/Makefile                |    8 +
>  drivers/virt/coco/sev-guest/Kconfig       |    1 
>  drivers/virt/coco/sev-guest/sev-guest.c   |  129 ++++++++++++-
>  drivers/virt/coco/tdx-guest/Kconfig       |    1 
>  drivers/virt/coco/tsm.c                   |  290 +++++++++++++++++++++++++++++
>  include/linux/slab.h                      |    2 
>  include/linux/tsm.h                       |   45 +++++
>  12 files changed, 535 insertions(+), 19 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-tsm
>  create mode 100644 drivers/virt/coco/Kconfig
>  create mode 100644 drivers/virt/coco/Makefile
>  create mode 100644 drivers/virt/coco/tsm.c
>  create mode 100644 include/linux/tsm.h
> 
> base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5

On Mon, Aug 14, 2023 at 11:04:52AM +0200, Jeremi Piotrowski wrote:

Good morning, I hope the week is going well for everyone.

> 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.
>
> I don't think sysfs is suitable for such concurrent
> transactions. Also if you think about exposing the sysfs interface
> to an application in a container, this requires bind mounting rw
> part of the sysfs tree into the mount namespace - not ideal.

We don't have a dog in this fight regarding TDX [1], but we do have a
significant body of experience with the concepts and challenges
involved.

The issue at hand is that trust is a resource that needs to be
orchestrated, just like any other resource.  A concept, based on our
experiences, that seems to be significantly outside of mainstream
thought.

The notion of the need to orchestrate trust seems to be particularly
important with a concept such as Confidential Containers.

FWIW, we have pushed forward a second round of patches for the kernel
infrastructure that make the concepts of trust orchestration and
containerization tenable:

https://lore.kernel.org/linux-security-module/20230710102319.19716-1-greg@enjellic.com/T/#t

In addition, FWIW, we have actually built systems that implement these
principals, obviously not on TDX hardware, see [1], but we do have a
significant body of experience with using SGX as a trust root.  We
have even provided a substantial set of initial userspace tooling that
implement these concepts to support the proposed patches.

I only say all of this to convey the notion that we have actually done
work on all of these concepts and are not just waving our hands
around.

The notion of surfacing this information through /sysfs becomes less
problematic if one approaches the issue through the lens of having
trust orchestrators that are responsible for managing the security or
trust status of the execution platform at large and any subordinate
workloads.

This concept is true, even if the platform/VM is only hosting a single
workload.  Which may be a necessity for some security contracts, where
there is literally no trust in the fact that side-channel disclosure
threats can be properly mitigated, ie. there cannot be workloads with
possible adversarial intents.

From the outside looking in, unless there are some fundamental
conversations regarding how trusted systems and workloads can be
developed with the architectures being proposed, it is completely
unclear how durable API's, on the order of 20+ years are ever going to
be attained.

No criticism, just observation.

> Jeremi

Best wishes for continued progress on all of this, it is important
stuff, both in the cloud and on the edge.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity

[1]: TDX enabled hardware is difficult, if not impossible to obtain.
If there is any doubt, simply search for TDX hardware availability and
cringe at the conversations on the Intel forums about people trying to
get experience with the technology.

This is the same problem that plagued TXT and SGX and results in
enabling infrastructure development being done in an echo chamber.  A
concept that may have proven successful when all of this work was
expected to be implementated and enabled by OEM providers but seems
problematic in an ostensibly 'community' driven project such as Linux.

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 don't think sysfs is suitable for such concurrent transactions. Also if you think
> about exposing the sysfs interface to an application in a container, this requires
> bind mounting rw part of the sysfs tree into the mount namespace - not ideal.

sysfs is not suitable for concurrent transactions. The container would
need to have an alternate path to request that the singleton owner of
the interface generate new reports, or use the boot time attestation to
derive per container communication sessions to the attestation agent.

On 8/14/2023 7:12 PM, Dan Williams 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?

It's not that it would become invalidated - it's that it will have served its purpose.
Attestation is used to establish trust with a relying party, for every other relying
party you'll need to generate a fresh attestation report. So we can't lock ourselves
into a specific protocol in the kernel here that only assumes a single party.

The one shot "decrypt disk image during boot" attestation use case is relevant elsewhere,
but not so much for containers.

> I am looking at "Table 21. ATTESTATION_REPORT Structure" for example and
> not seeing data there that changes from one request to the next.

REPORT_DATA in SNP or REPORTDATA in TDX. You want to have a nonce/challenge or short
lived session keys covered by the report, so you hash some data structure that includes
them and request an attestation report with the hash in "report data".

Here's an example of the verifying side:
https://github.com/confidential-containers/attestation-service/blob/main/attestation-service/src/verifier/tdx/mod.rs#L40-L52


> Runtime validation likely looks more like the vTPM use case with PCRs. That will
> leverage the existing / common TPM ABI.> 

Not at all, these two things are orthogonal. PCRs can be extended at runtime but you'll
struggle to use them as described above. You'd have to designate a PCR for this purpose,
lock against concurrent users (across multiple TPM commands) and reset it before every
use. Highly impractical.

TPM2 has a similar concept to "REPORTDATA" called "qualifying data" which is passed
when requesting a quote. This highlights the need for an interface to regenerate evidence
(attestation report or quote) with user defined data mixed in.

>> I don't think sysfs is suitable for such concurrent transactions. Also if you think
>> about exposing the sysfs interface to an application in a container, this requires
>> bind mounting rw part of the sysfs tree into the mount namespace - not ideal.
> 
> sysfs is not suitable for concurrent transactions. The container would
> need to have an alternate path to request that the singleton owner of
> the interface generate new reports, or use the boot time attestation to
> derive per container communication sessions to the attestation agent.

It would be possible to use a userspace agent to coordinate access to generating reports,
but that takes us further away from standardization - applications would have to be
tailored to a specific environment instead of relying on the same kernel (hardware)
interface everywhere.

I don't follow this part:
"use the boot time attestation to derive per container communication sessions to the attestation agent".
In general we want the application attestation report to be linked directly to a hardware
root of trust, without chaining through some intermediate entity.

On Mon, Aug 14, 2023 at 11:12 AM Dan Williams <dan.j.williams@intel.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?

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? Some users may prefer less overall code within their Trusted
Computer Base (TCB) and a TPM emulate is a significant code base.

It seems like you are just reading the SNP spec, 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.

>
> > I don't think sysfs is suitable for such concurrent transactions. Also if you think
> > about exposing the sysfs interface to an application in a container, this requires
> > bind mounting rw part of the sysfs tree into the mount namespace - not ideal.
>
> sysfs is not suitable for concurrent transactions. The container would
> need to have an alternate path to request that the singleton owner of
> the interface generate new reports, or use the boot time attestation to
> derive per container communication sessions to the attestation agent.

Peter Gonda wrote:
> On Mon, Aug 14, 2023 at 11:12 AM Dan Williams <dan.j.williams@intel.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.

>
> 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? Some users may prefer less overall code within their Trusted
> Computer Base (TCB) and a TPM emulate is a significant code base.
>

I agree, and I was a bit too hasty to acquiesce to sysfs due to the
TPM argument that really only applies for SEV-SNP without a whole lot
of extra work for other backends (not to say SVSM isn't itself a whole
lot of extra work).

> It seems like you are just reading the SNP spec, 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.
>

I'll add a note here that measurement registers are extensible at any
point by ring0, and there should be an API for doing so, the way that
there is for /dev/tpmX.

It could be /dev/teemr or something to unify TDX, COVE, ARM CCA, and
potentially a measurement register protocol extension to SEV-SNP's
SVSM.
I'm not sure how Intel is going to propose abstracting TCG Canonical
Event Log measurements to reuse measurement-to-PCR<X> code points in
the kernel as measurement-to-MR<f(X)>, or whatnot, but each technology
should have that implementation option to extend their own measurement
registers (and event log, potentially).

I (and probably James) object with just saying the PCRs are going to
xyz-measurement-register for simulating that integrity part of a TPM
to get just the quote aspect and not the rest of TPM 2.0 to hide
everything behind the TPM abstraction. It doesn't follow the Tcg spec.

But I repeat myself. If we use any ioctl, we'll end up multiplexing
the input per-technology, and at that point we essentially have
manufacturer-specific devices much to Dan's dismay.

Sysfs will certainly not be okay for measurement register-only
technology, since there's no way to not use a hardware attestation to
securely track measurement changes past "the static boot" (PCRs 0-7).
I don't want to have to rely on enclave-like peer VMs that perform the
TPM behavior.

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

Dionna Amalie Glaze wrote:
> >
> > 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? Some users may prefer less overall code within their Trusted
> > Computer Base (TCB) and a TPM emulate is a significant code base.
> >
> 
> I agree, and I was a bit too hasty to acquiesce to sysfs due to the
> TPM argument that really only applies for SEV-SNP without a whole lot
> of extra work for other backends (not to say SVSM isn't itself a whole
> lot of extra work).
> 
> > It seems like you are just reading the SNP spec, 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.
> >
> 
> I'll add a note here that measurement registers are extensible at any
> point by ring0, and there should be an API for doing so, the way that
> there is for /dev/tpmX.
> 
> It could be /dev/teemr or something to unify TDX, COVE, ARM CCA, and
> potentially a measurement register protocol extension to SEV-SNP's
> SVSM.
> I'm not sure how Intel is going to propose abstracting TCG Canonical
> Event Log measurements to reuse measurement-to-PCR<X> code points in
> the kernel as measurement-to-MR<f(X)>, or whatnot, but each technology
> should have that implementation option to extend their own measurement
> registers (and event log, potentially).
> 
> I (and probably James) object with just saying the PCRs are going to
> xyz-measurement-register for simulating that integrity part of a TPM
> to get just the quote aspect and not the rest of TPM 2.0 to hide
> everything behind the TPM abstraction. It doesn't follow the Tcg spec.
> 
> But I repeat myself. If we use any ioctl, we'll end up multiplexing
> the input per-technology, and at that point we essentially have
> manufacturer-specific devices much to Dan's dismay.

I think the ioctl() question is separate from the question of how to
scale an attestation ABI.

While I am not yet convinced that RTMR deserves an ABI separate from
vTPM (or at least a trusted-keys abstraction to reuse the kernel's
existing PCR ABI for TPM-like facilities) the selection of sysfs
precludes the "RTMR and repeated measurements by multiple containers"
use case. One way to buy time for that future conversation while moving
ahead on this base reporting ABI is to switch from sysfs to configfs.
That would allow for per container submission ABI.

It could be approximated with sysfs by having an instance creation
attribute, but it is more natural to just use mkdir to create more
interfaces that can be bind mounted by per-container if need be.

> Sysfs will certainly not be okay for measurement register-only
> technology, since there's no way to not use a hardware attestation to
> securely track measurement changes past "the static boot" (PCRs 0-7).
> I don't want to have to rely on enclave-like peer VMs that perform the
> TPM behavior.

Understood.