Re: [PATCH v2 0/5] tsm: Attestation Report ABI

[Dr. Greg]

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@xxxxxxxxxxxx/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.