SNP-related commands about sevctl

[crobinso]

I agree we need some differentiation. Another option is sevctl measurement {sev,snp} .... If we add sevctl secret build as well then maybe it would need similar treatment.

Adding a sevctl sev namespace might be a little ambiguous since all the current commands are already sev commands.

I guess this probably only matters with commands that don't need to be run on sev host. Do you expect we can transparently make all of those work on SNP hosts, or explicitly error if the command isn't relevant? Then maybe it's best to restrict the sev vs snp namespace to the subcommands we know require differentiation that we can't detect at runtime.

[tylerfanelli]

An example I think of is sevctl export. Both commands for SEV and SNP would do the same thing (export the certificate chain). The only difference would be that the certificate chains are different for each architecture, so essentially it would make no sense to run sevctl export on an SNP machine at the moment. If we were to add a command to do this for SNP, we would need to distinguish between the two. Somthing like sevctl ok needn't concern itself with this, as it works the same on both architectures.

[crobinso]

Hmm I see. I didn't consider that you may want to run both SEV and SNP commands on an SNP machine, which can support both. If we need to differentiate that for most commands then I think either sevctl snp or snpctl makes sense.

[tylerfanelli]

snpctl was previously discussed, and ultimately the conclusion that was reached is just to continue using sevctl, as SNP is still a SEV generation (and not a completely different TEE architecture altogether, depending on how you view it).

Is there a strong case to be made for creating snpctl instead of using sevctl to house these commands? I don't really see a convincing argument, yet I'm still open to the idea.