tpm-rs
Replies: 3 comments 3 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
@daprilik - this appears to be a dupe (or mostly a dupe) of #9 ? do we need both? I think we agree with the goal. Do we need the discussions open? |
Beta Was this translation helpful? Give feedback.
-
|
These two issues discuss two distinct, but interconnected concepts: #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. #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 #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 #10, due to difficulties with how state is managed in the C implementation. Similarly, its entirely possible to design tpm-rs with support for #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:
|
Beta Was this translation helpful? Give feedback.
-
|
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 #10)
These two issues discuss two distinct, but interconnected concepts: #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. #10 is about
These two issues discuss two distinct, but interconnected concepts:
#9<#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.
#10<#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 #9<#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 #10<#10>, due to difficulties with how state is managed in the C implementation.
Similarly, its entirely possible to design tpm-rs with support for #10<#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<#10 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAOJLREKDOCS77SM6MIEHKTZYLSKVAVCNFSM6AAAAABOS64VVOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANZVGQYDAMQ>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
@stefanberger - is your vTPM implementation visible in github? Would you mind sharing a pointer? |
Beta Was this translation helpful? Give feedback.
-
|
libtpms: https://github.com/stefanberger/libtpms |
Beta Was this translation helpful? Give feedback.
-
tpm-rswill emit persistent saved-state blobs, and assuming we're all on the same page about #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-rsshould support upgrading saved state blobs between versions, and/or running newertpm-rsbuilds using oldertpm-rssaved-state blobs.Beta Was this translation helpful? Give feedback.
All reactions