[DISCUSSION] svsm: attestation + CocoonFs:

[DISCUSSION] svsm: attestation + CocoonFs:

[Nicolai Stange]

Hi Tyler,

I've been told in one of the svsm devel calls that a capability for
storing some info in plaintext in CocoonFs would be helpful for your
attestation efforts.

Before I go and implement something, let me ask about the nature of that
data.
- What exactly are you planning to store there?
- Presumably the filesystem salt from the image header, supposed to also
  serve as a filesystem ID ([1]), is not sufficient?
- Is the data considered immutable over the lifetime of the FS?
- Is it Ok if that data is not authenticated?

Thanks!

Nicolai

[1] https://coconut-svsm.github.io/cocoon-tpm/cocoonfs/cocoonfs-format.html#image-header

Re: [DISCUSSION] svsm: attestation + CocoonFs:

[Arun Menon]

On Wed, Mar 11, 2026 at 05:29:30AM +0100, Nicolai Stange wrote:
> Hi Tyler,
> 
> I've been told in one of the svsm devel calls that a capability for
> storing some info in plaintext in CocoonFs would be helpful for your
> attestation efforts.
> 
> Before I go and implement something, let me ask about the nature of that
> data.
> - What exactly are you planning to store there?
> - Presumably the filesystem salt from the image header, supposed to also
>   serve as a filesystem ID ([1]), is not sufficient?
> - Is the data considered immutable over the lifetime of the FS?
> - Is it Ok if that data is not authenticated?
> 
> Thanks!
> 
> Nicolai
> 
> [1] https://coconut-svsm.github.io/cocoon-tpm/cocoonfs/cocoonfs-format.html#image-header

Hi Nicolai,

I’m jumping in here — while I’m not Tyler, I’ve been working under
his guidance on a related provisioning flow and wanted to share my
understanding to see if it aligns with the requirement being discussed.

In my current workflow, we are pre-provisioning a TPM state file
(including the EK cert) on a separate host (not necessarily confidential).
The goal is to have the SVSM-based TPM start with this known state file.

Here is how I envision the flow:
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]
2. Packaging: Create a CocoonFS image containing this state file, encrypted
   with a key Key1.
3. Key Management: Send Key1 to a Key Broker Service (KBS) and receive a
   wrapped version, Key2.
4. Header Storage: Store the wrapped key Key2 in the CocoonFS image
   header.

At Runtime in the SVSM: SVSM reads the header to retrieve the wrapped
key Key2. SVSM sends Key2 along with the hardware attestation report
to the KBS. The KBS validates the report and returns the unwrapped key
Key1. SVSM uses Key1 to decrypt the CocoonFS image and access the
TPM state.

To address your specific question, in this scenario, the wrapped key
Key2 needs to be accessible before the filesystem is decrypted. If
the image header can store this metadata in a way that SVSM can parse it
without the primary filesystem key, it would solve the bootstrapping
problem of how to get the key from the KBS.

Does this match the type of metadata you were considering, or was it
intended for a different purpose?


[1] https://github.com/armenon-rh/tpm_provisioner


Regards,
Arun Menon

Re: [DISCUSSION] svsm: attestation + CocoonFs:

[James Bottomley]

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 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) 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.

Regards,

James

Re: [DISCUSSION] svsm: attestation + CocoonFs:

[Tyler Fanelli]

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

Re: [DISCUSSION] svsm: attestation + CocoonFs:

[Tyler Fanelli]

Hi Nicolai,

Apologies for the late response.

On 3/11/26 12:29 AM, Nicolai Stange wrote:
> Hi Tyler,
> 
> I've been told in one of the svsm devel calls that a capability for
> storing some info in plaintext in CocoonFs would be helpful for your
> attestation efforts.
> 

Correct!

> Before I go and implement something, let me ask about the nature of that
> data.
> - What exactly are you planning to store there?

Here's a rough outline of our plans:

The CocoonFS images will be encrypted. Within the CocoonFS headers, we'd 
like to include the *wrapped* key used for decrypting the image.

Once SVSM will attest, it will read the wrapped key from CocoonFS and 
forward it to an attestation server and receive it back unwrapped. Since 
SVSM is now itself measured, we can ensure that it will not do anything 
nefarious with the unwrapped key, which is sensitive data and cannot be 
leaked.

With this, we don't have to worry about storing different keys on 
attestation servers and identifying which key belongs to which CocoonFS 
image. The image will carry its key alongside it, yet it will be 
wrapped, and attestation will be required for any unwrapping.

> - Presumably the filesystem salt from the image header, supposed to also
>    serve as a filesystem ID ([1]), is not sufficient.

Not for this purpose.

> - Is the data considered immutable over the lifetime of the FS?

Yes, the key is immutable.

> - Is it Ok if that data is not authenticated?
> 

I'd say it likely *should* be authenticated to ensure tampering didn't 
take place? I'm open to discussion on this, however.


Tyler