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

[Jeremi Piotrowski]

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@xxxxxxxxxxxxxxx
> 
> ---
> 
> 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