Re: [DISCUSSION] svsm: attestation + CocoonFs:

Tyler Fanelli <[email protected]> Thu, 19 Mar 2026 12:38:35 -0400
Newsgroups dev.linux.lists.coconut-svsm
Message-ID <[email protected]>
On 3/19/26 10:04 AM, James Bottomley wrote:
> On Thu, 2026-03-19 at 17:30 +0530, Arun Menon wrote:
> [...]
>> 1. Provisioning: Generate a TPM state file (NVChip) externally with
>> the EK cert and other metadata. The tool starts TCG TPM simulator and
>> then    writes an EK cert to the state file. [1]
> 
> Just a couple of notes about this: firstly your tool seems to generate
> an ephemeral CA and then sign the EK cert with that.  The problem with
> this is that it's the X.509 chain of trust (to the CA) which gives a
> persistent TPM its proof of trust.  An ephemeral CA basically voids
> that so what's the point of the EK cert?
> 

The tool isn't complete yet. At some point a user will be able (and 
likely required) to give their own CA to sign the EK.

> The next problem is how should we correctly prove trust in the
> persistent TPM?
> 
> Obviously, for an ephemeral TPM the proof of trust is the Launch
> Measurement (verifying the implementation) followed by an attestation
> of the EK by the SVSM obviating the need for an EK cert.
> 
> However, for a persistent TPM, the proof of trust would have to be
> something like the launch measurement (proving correct operation)

The CocoonFS decryption key is stored on an attestation server, with 
release/unwrapping only permitted upon successful attestation (i.e. the 
launch measurement and other parameters). This is how we prove correct 
operation.

> plus
> something tying the current TPM state to the proof of non tampering
> with CocoonFS itself. 
> The EK isn't proof of this because if something> compromises CocoonFS it can leak the EK seed and an attacker can
> replicate the state including a correct EK.
> 

Is that the responsibility of the TPM? If something is within encrypted 
storage, is it really up to that data to ensure that its storage hasn't 
be tampered with?

If it is, perhaps we can embed some extra metadata alongside the TPM for 
some form of integrity validation (a boot counter, perhaps?), yet at the 
moment there is nothing strictly coupling the TPM with the CocoonFS.


Tyler