Add a compatibility matrix #1259

bpradipt · 2026-01-07T14:14:49Z

I took help from AI agent to pull up the details. Keeping it in draft for the following reasons:

Get early feedback on whether something like this will be useful to make it easier for users and adopters to know which version of guest-components will work with Trustee
Correctness of the data

cc @confidential-containers/guest-components-maintainers @confidential-containers/trustee-maintainers

Having compatibility matrix for guest-components and trustee to make it easier for users/adopters Signed-off-by: Pradipta Banerjee <[email protected]>

fitzthum

Something like this could make sense. I wonder if we will be able to keep it up-do-date and if this is the right place for it. Maybe in coco/coco or the release notes or the website would make more sense?

There are a number of errors in this doc as well I think.

fitzthum · 2026-01-07T14:24:48Z

COMPATIBILITY.md

+| TEE Platform       | `TEE_PLATFORM` | Attester Feature Flag |
+|--------------------|----------------|-----------------------|
+| Intel TDX          | `tdx`          | `tdx-attester`        |
+| Intel SGX          | (manual)       | `sgx-attester`        |


not sure what manual is

fitzthum · 2026-01-07T14:25:16Z

COMPATIBILITY.md

+| ARM CCA            | v0.10.0+         | v0.10.0+ | aarch64      | Experimental |
+| IBM Secure Exec    | v0.10.0+         | v0.10.0+ | s390x        | Stable       |
+| Hygon CSV          | v0.12.0+         | v0.12.0+ | x86_64       | Experimental |
+| NVIDIA GPU         | v0.15.0+         | v0.15.0+ | x86_64       | Experimental |


NVIDIA should be stable now.

Are we missing TPM here?

Yeah.
Wondering do we need to add this level of details or just leave at GC and Trustee version ? Might become hard to maintain going forward. Wdyt ?

fitzthum · 2026-01-07T14:25:34Z

COMPATIBILITY.md

+| Intel TDX          | v0.8.0+          | v0.8.0+  | x86_64       | Stable       |
+| Intel SGX          | v0.7.0+          | v0.7.0+  | x86_64       | Stable       |
+| AMD SEV-SNP        | v0.7.0+          | v0.7.0+  | x86_64       | Stable       |
+| AMD SEV(-ES)       | v0.7.0+          | v0.7.0+  | x86_64       | Stable       |


Not supported anymore, although I'm not sure if we've ripped the code out of GC yet.

so add a table of retired TEEs?

fitzthum · 2026-01-07T14:27:08Z

COMPATIBILITY.md

+- Changed attestation evidence format for some platforms
+
+### v0.8.0+
+- Initial stable KBS protocol v0.4.0


This doesn't seem right. v0.4.0 would have been after multi-device attestation (v0.3.0) and init-data plaintext support (v0.4.0)

protocol history details is in this issue confidential-containers/trustee#907

fitzthum · 2026-01-07T14:28:13Z

COMPATIBILITY.md

+
+   # Test with guest-components client
+   cd attestation-agent
+   cargo test --features kbs


Not sure if either of these tests will actually work. I think the unit test will be skipped if the version doesn't match. At least someone should try running this.

I would drop that section from this doc as well.

Xynnn007

Nice document!

Xynnn007 · 2026-01-08T01:50:58Z

COMPATIBILITY.md

+| v0.14.0      | v0.13.0          | v0.13.0  | v0.4.0       | May 2025     |
+| v0.13.0      | v0.12.0          | v0.12.0  | v0.4.0       | Mar 2025     |
+
+**Note:** Using mismatched versions may work but is not tested. For production deployments, use versions from the same CoCo release.


This will not work. There is version check logic https://github.com/confidential-containers/trustee/blob/main/kbs/src/attestation/backend.rs#L220-L227 to assert the versions are the same?

Xynnn007 · 2026-01-08T01:52:47Z

COMPATIBILITY.md

+| Azure SNP vTPM     | v0.9.0+          | v0.9.0+  | x86_64       | Stable       |
+| ARM CCA            | v0.10.0+         | v0.10.0+ | aarch64      | Experimental |
+| IBM Secure Exec    | v0.10.0+         | v0.10.0+ | s390x        | Stable       |
+| Hygon CSV          | v0.12.0+         | v0.12.0+ | x86_64       | Experimental |


We also have Hygon DCU from v0.15.0

mkulke · 2026-01-08T07:16:25Z

COMPATIBILITY.md

+
+## KBS Protocol Version
+
+Guest-components and Trustee communicate using the KBS (Key Broker Service) protocol. Both sides must use compatible protocol versions.


Currently we have no enforced schema for the evidence payload, so if some encoding changes (e.g. because of a bincode update/replacement in GC or in a dependency). a change on the payload would break Trustee interop. Until we have this, it's an aspirational goal, but we cannot really guarantee this.

mythi · 2026-01-08T11:33:01Z

Something like this could make sense. I wonder if we will be able to keep it up-do-date and if this is the right place for it. Maybe in coco/coco or the release notes or the website would make more sense?

These would be my concerns and questions too. The release notes would force us to keep it regularly updated (or the release checklist could have an item to update this doc in its own file at least)

wainersm · 2026-01-09T13:25:49Z

COMPATIBILITY.md

+| Hygon CSV          | v0.12.0+         | v0.12.0+ | x86_64       | Experimental |
+| NVIDIA GPU         | v0.15.0+         | v0.15.0+ | x86_64       | Experimental |
+
+### Feature Flags


This Feature Flags seems more for the guest-component's main documentation than for this compatibility document. I would drop it.

wainersm · 2026-01-09T13:27:04Z

COMPATIBILITY.md

+| ARM CCA            | `cca`          | `cca-attester`        |
+| IBM Secure Exec    | `se`           | `se-attester`         |
+
+## Component Dependencies


Likewise. That section is more like an internal implementation detail of guest-components.

wainersm · 2026-01-09T13:34:18Z

Something like this could make sense. I wonder if we will be able to keep it up-do-date and if this is the right place for it. Maybe in coco/coco or the release notes or the website would make more sense?

These would be my concerns and questions too. The release notes would force us to keep it regularly updated (or the release checklist could have an item to update this doc in its own file at least)

IMO that document should be moved to https://github.com/confidential-containers/confidential-containers/ , have a link on release notes and a item in the release checklist to remember us of getting it up-to-date.

wainersm · 2026-01-09T13:34:54Z

Something like this could make sense. I wonder if we will be able to keep it up-do-date and if this is the right place for it. Maybe in coco/coco or the release notes or the website would make more sense?

These would be my concerns and questions too. The release notes would force us to keep it regularly updated (or the release checklist could have an item to update this doc in its own file at least)

IMO that document should be moved to https://github.com/confidential-containers/confidential-containers/ , have a link on release notes and a item in the release checklist to remember us of getting it up-to-date.

Ah, I was about to forget: amazing document! thanks @bpradipt !

Add a comptability matrix

8cd4491

Having compatibility matrix for guest-components and trustee to make it easier for users/adopters Signed-off-by: Pradipta Banerjee <[email protected]>

fitzthum reviewed Jan 7, 2026

View reviewed changes

Xynnn007 reviewed Jan 8, 2026

View reviewed changes

mkulke changed the title ~~Add a comptability matrix~~ Add a compatibility matrix Jan 8, 2026

mkulke reviewed Jan 8, 2026

View reviewed changes

wainersm reviewed Jan 9, 2026

View reviewed changes


		## KBS Protocol Version

		Guest-components and Trustee communicate using the KBS (Key Broker Service) protocol. Both sides must use compatible protocol versions.

Add a compatibility matrix #1259

Are you sure you want to change the base?

Add a compatibility matrix #1259

Uh oh!

Conversation

bpradipt commented Jan 7, 2026

Uh oh!

fitzthum left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Xynnn007 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mythi commented Jan 8, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wainersm commented Jan 9, 2026

Uh oh!

wainersm commented Jan 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants