On 07/12/2023 18:21, Jeremi Piotrowski wrote:
On 07/12/2023 13:58, Huang, Kai wrote:
That's how it currently works - all the enlightenments are in hypervisor/paravisor specific code in arch/x86/hyperv and drivers/hv and the vm is not marked with X86_FEATURE_TDX_GUEST.
And I believe there's a reason that the VM is not marked as TDX guest.
Yes, as Elena said: """ OK, so in your case it is a decision of L1 VMM not to set the TDX_CPUID_LEAF_ID to reflect that it is a tdx guest and it is on purpose because you want to drop into a special tdx guest, i.e. partitioned guest. """ TDX does not provide a means to let the partitioned guest know that it needs to cooperate with the paravisor (e.g. because TDVMCALLs are routed to L0) so this is exposed in a paravisor specific way (cpuids in patch 1).
But without X86_FEATURE_TDX_GUEST userspace has no unified way to discover that an environment is protected by TDX and also the VM gets classified as "AMD SEV" in dmesg. This is due to CC_ATTR_GUEST_MEM_ENCRYPT being set but X86_FEATURE_TDX_GUEST not.
Can you provide more information about what does _userspace_ do here?
I gave one usecase in a different email. A workload scheduler like Kubernetes might want to place a workload in a confidential environment, and needs a way to determine that a VM is TDX protected (or SNP protected) to make that placement decision.
What's the difference if it sees a TDX guest or a normal non-coco guest in /proc/cpuinfo?
Looks the whole purpose of this series is to make userspace happy by advertising TDX guest to /proc/cpuinfo. But if we do that we will have bad side-effect in the kernel so that we need to do things in your patch 2/3.
Yes, exactly. It's unifying the two approaches so that userspace doesn't have to care.
That doesn't seem very convincing.
Why not? The whole point of the kernel is to provide a unified interface to userspace and abstract away these small differences. Yes it requires some kernel code to do, thats not a reason to force every userspace to implement its own logic. This is what the flags in /proc/cpuinfo are for.
So I feel like we're finally getting to the gist of the disagreements in this thread.
Here's something I think we should all agree on (both a) and b)). X86_FEATURE_TDX_GUEST: a) is visible to userspace and not just some kernel-only construct b) means "this is a guest running in an Intel TDX Trust Domain, and said guest is aware of TDX"
a) is obvious but I think needs restating. b) is what userspace expects, and excludes legacy (/unmodified) guests running in a TD. That's a reasonable definition.
For kernel only checks we can rely on platform-specific CC_ATTRS checked through intel_cc_platform_has.
@Borislav: does that sound reasonable to you? @Kai, @Kirill, @Elena: can I get you to agree with this compromise, for userspace' sake?
Jeremi