Versioning and upgrading between tpm-rs versions

[daprilik]

tpm-rs will emit persistent saved-state blobs, and assuming we're all on the same page about tpm-rs/project-wide-discussions#9, volatile saved state blobs as well.

Most (all?) existing TPM implementation emit saved state that it entirely un-versioned, resulting in tight-coupling between saved-state blobs and the particular TPM library revision that generated them.

This might be fine for a "fire and forget" TPM running on a physical device... but it becomes quite unfortunate in Virtual TPM (vTPM) contexts, where it's entirely possible (and desirable!) to update the underlying vTPM device code as new revisions come out.

Barring an upgrade path, any VMM that wishes to update its vTPM revision (without breaking existing VMs) would be required to start shipping multiple vTPM revisions at the same time, which is often non-trivial, and comes with a plethora of implementation and long-term maintainability challenges.

tpm-rs should support upgrading saved state blobs between versions, and/or running newer tpm-rs builds using older tpm-rs saved-state blobs.

[stefanberger]

Barring an upgrade path, any VMM that wishes to update its vTPM revision (without breaking existing VMs) would be required to start shipping multiple vTPM revisions at the same time, which is often non-trivial, and comes with a plethora of implementation and long-term maintainability challenges.

libtpms tries to add versioning and possibly even downgrading via command/algorithm profiles support to TPM 2 but, yes, it does come with implementation and long-term maintainability challenges and in the worst case in can end up in a dead-end.

[bradlitterell]

@daprilik - this appears to be a dupe (or mostly a dupe) of tpm-rs/project-wide-discussions#9 ? do we need both? I think we agree with the goal. Do we need the discussions open?

[daprilik]

These two issues discuss two distinct, but interconnected concepts:

tpm-rs/project-wide-discussions#9 is about building support for runtime state persistence, enabling key VM scenarios like runtime save/restore/pause/resume to work correctly with a vTPM device.

tpm-rs/project-wide-discussions#10 is about supporting versioning / upgrading between different versions of tpm-rs, which itself could be broken down into two components - enabling versioned non-volatile state, as well as enabling versioning volatile runtime state.

In Hyper-V, we hand-rolled our own implementation of tpm-rs/project-wide-discussions#9 in the context of the ms-tpm-20-ref codebase, but as I'm sure you're aware, we haven't been able to do the same with tpm-rs/project-wide-discussions#10, due to difficulties with how state is managed in the C implementation.

Similarly, its entirely possible to design tpm-rs with support for tpm-rs/project-wide-discussions#10 purely in the context of non-volatile state, without building support for saving / upgrading / migrating volatile runtime state (i.e: requiring the TPM device to be 'powered off' in order for it to be updated).

As such, I submit the following opinions:

• Ideally, we'd want both 9 and 10, as that would give us a complete, 'no-compromises' way to enable stable user-facing TPM devices on-top of a single evolving codebase.
• Agreeing that we want both 9 and 10 from the get-go will make it far easier to design an appropriate state-management subsystem in tpm-rs. History has proven that bolting on versioning / volatile-state persistence after-the-fact is not easy.

[stefanberger]

FYI: For the vTPM for QEMU+KVM I am now also supporting downgrading of state, meaning that an older version of the TPM implementation can read and run the state written by a newer version. This includes masking of TPM functionality of a newer version with profiles written in JSON so that newer functionality is basically hidden from applications running inside a VM. Regards, Stefan

…

________________________________ From: Daniel Prilik ***@***.***> Sent: Wednesday, September 25, 2024 12:47 PM To: tpm-rs/project-wide-discussions ***@***.***> Cc: Stefan Berger ***@***.***>; Comment ***@***.***> Subject: [EXTERNAL] Re: [tpm-rs/project-wide-discussions] Versioning and upgrading between `tpm-rs` versions (Discussion tpm-rs/project-wide-discussions#10) These two issues discuss two distinct, but interconnected concepts: tpm-rs/project-wide-discussions#9 is about building support for runtime state persistence, enabling key VM scenarios like runtime save/restore/pause/resume to work correctly with a vTPM device. tpm-rs/project-wide-discussions#10 is about These two issues discuss two distinct, but interconnected concepts: tpm-rs/project-wide-discussions#9<https://github.com/orgs/tpm-rs/discussions/9> is about building support for runtime state persistence, enabling key VM scenarios like runtime save/restore/pause/resume to work correctly with a vTPM device. tpm-rs/project-wide-discussions#10<https://github.com/orgs/tpm-rs/discussions/10> is about supporting versioning / upgrading between different versions of tpm-rs, which itself could be broken down into two components - enabling versioned non-volatile state, as well as enabling versioning volatile runtime state. In Hyper-V, we hand-rolled our own implementation of tpm-rs/project-wide-discussions#9<https://github.com/orgs/tpm-rs/discussions/9> in the context of the ms-tpm-20-ref codebase, but as I'm sure you're aware, we haven't been able to do the same with tpm-rs/project-wide-discussions#10<https://github.com/orgs/tpm-rs/discussions/10>, due to difficulties with how state is managed in the C implementation. Similarly, its entirely possible to design tpm-rs with support for tpm-rs/project-wide-discussions#10<https://github.com/orgs/tpm-rs/discussions/10> purely in the context of non-volatile state, without building support for saving / upgrading / migrating volatile runtime state (i.e: requiring the TPM device to be 'powered off' in order for it to be updated). As such, I submit the following opinions: * Ideally, we'd want both 9 and 10, as that would give us a complete, 'no-compromises' way to enable stable user-facing TPM devices on-top of a single evolving codebase. * Agreeing that we want both 9 and 10 from the get-go will make it far easier to design an appropriate state-management subsystem in tpm-rs. History has proven that bolting on versioning / volatile-state persistence after-the-fact is not easy. ? Reply to this email directly, view it on GitHub<https://github.com/orgs/tpm-rs/discussions/10#discussioncomment-10754002>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAOJLREKDOCS77SM6MIEHKTZYLSKVAVCNFSM6AAAAABOS64VVOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANZVGQYDAMQ>. You are receiving this because you commented.Message ID: ***@***.***>

[bradlitterell]

@stefanberger - is your vTPM implementation visible in github? Would you mind sharing a pointer?

[stefanberger]

libtpms: https://github.com/stefanberger/libtpms
swtpm: https://github.com/stefanberger/swtpm