Evaluate dependency of PCKIDRetrievalTool

[tylerfanelli]

Part of the fetch-pck subcommand requires the use of PCKIDRetrievalTool.

https://github.com/elmarco/cvmtool/blob/ef747665e6f23b613ff644d8b78ecd8f1144e495/src/pck.rs#L30-L33

This is part of Intel's DCAP tools: https://github.com/intel/confidential-computing.tee.dcap/tree/main/tools/PCKRetrievalTool

Ideally we wouldn't want that tool to be a hard dependency on this crate. Is there a way to implement what it does directly here?

cc/ @berrange

[berrange]

I think we should consider whether 'fetch-pck' should be in scope or not.

The 'report' and 'verify' commands are both targetted at guest OS owners.

The 'fetch-pck' command is different in that it has to be run by the host OS owner, and the results given to the guest OS owner. This different audience perhaps points towards it being out of scope for cvmtool.

This is part of Intel's DCAP tools: https://github.com/intel/confidential-computing.tee.dcap/tree/main/tools/PCKRetrievalTool

Ideally we wouldn't want that tool to be a hard dependency on this crate. Is there a way to implement what it does directly here?

Nothing practical AFAIK. PCKRetrievalTool needs to load SGX enclaves to do its job and there's no native rust code that can do that. The best you'd get is using the SGX native libraries to re-impl PCKRetrievalTool's logic, which leads you with essentially the same native code dep, just via a library API instead of subprocess so marginally better error handling.

[tylerfanelli]

I think we should consider whether 'fetch-pck' should be in scope or not.

The 'report' and 'verify' commands are both targetted at guest OS owners.

The 'fetch-pck' command is different in that it has to be run by the host OS owner, and the results given to the guest OS owner. This different audience perhaps points towards it being out of scope for cvmtool.

I hadn't realized this. If this is a guest-focused tool, then fetch-pck doesn't belong.

We have snphost for configuring the SEV-SNP environment on a host machine. Perhaps there could be a tdxhost equivalent for TDX.

Since all guests are using configfs-tsm for their attestation evidence, it makes sense to provide this one tool for all architectures. However, the differences in configuring the host environment differs radically for different TEE architectures, so I think separate tools (snphost, tdxhost, etc...) are warranted.

[berrange]

We have snphost for configuring the SEV-SNP environment on a host machine. Perhaps there could be a tdxhost equivalent for TDX.

In the AMD case we created sevctl and later snphost because AMD didn't provide any production quality tools themselves - their C++ impl was more of a technology demonstrator.

In the Intel case, the host tools are part of the pre-existing SGX software stack which is established for 10+ years already, so we probably don't need to invest in creating a new tdxhost tool.

[tylerfanelli]

Sounds good to me.