Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP

[Dionna Amalie Glaze <dionnaglaze@google.com>]

On Wed, Mar 22, 2023 at 11:08 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Wed, Mar 22, 2023 at 10:15:33AM +0100, Jörg Rödel wrote:
> > There is of course work building on linux-svsm out there, too. It would
> > be interesting to get an overview of that. We are already looking into
> > porting over the attestation code IBM wrote for linux-svsm (although we
> > would prefer IBM submitting it :) ). The vTPM code out there can not be
> > ported over as-is, as COCONUT will not link a whole TPM library in its
> > code-base. But maybe it can be the base for a separate vTPM binary run
> > by COCONUT.
>
> For whichever SVSM impl becomes the dominant, the vTPM support with
> persistence, is something I see as a critical component. It lets the
> guest OS boot process at least be largely decoupled from the CVM
> attestation process, and instead rely on the pre-existing support for
> TPMs, SecureBoot & secret sealing which is common to bare metal and
> non-confidential VM deployments alike.
>

NVDATA in a confidential setting in my mind needs a whole an attested
sealing key escrow service to really remove the host from the trust
boundary.
Ideally the service never goes down and can have an unbroken chain of
custody back to the original ingestion into the service.
If the service ever has all machines go down, it would have to have
another trusted service of rollback-safe files. That depends on
trusted time.

The service nodes plays hot potato with key replication and has logged
and attested cluster management operations:
*  sealing secrets forward to a new version that was signed by a
pre-registered trusted operator.
*  adding more machines to a cluster that has access to the secrets by
a trusted operator.
*  the sealing enclaves themselves need a secure source of time to
know when the enclave came up and whether it got its secrets from a
rollback-safe sealed-to-code file or will depend on gossip.

Trusted persistence really means there's some trusted workload that
never goes down that is able to take a sealing key bound to an
expected workload measurement and return a secret that will only be
unsealed when the vTPM gets to the bound measurement.

It's a fun problem, one I've been wanting to work on, but yeah there's
a bunch of other more pressing work to do first.

> With regards,
> Daniel
> --
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
>


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