Re: [DISCUSSION] svsm: attestation + CocoonFs:

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