Introduce Enhanced SMT Protection for SEV-SNP

Enhanced SMT Protection (ESMTP) allows an SEV-SNP VM to require that, while one of its vCPUs is in guest mode, every SMT sibling thread on that physical core is either idle in host mode or running a vCPU the guest itself has declared a legal sibling. This mitigates the side-channel risk of sharing core resources with untrusted host threads or with another guest.

Unlike core scheduling, where co-residency is a host kernel policy expressed with cookies, ESMTP is enforced by hardware. The sibling mask lives in the VMSA. The host is not trusted to run arbitrary kernel, userspace, or interrupt-handling work on a sibling thread while an ESMTP vCPU is active on that core.

Both KVM and the guest fully set the VCPU_SIBLING_MASK, which places every vCPU of the guest in one group so that any two of them may be co-resident. Combined with the ASID check, the sibling of a vCPU in guest mode is then always either another vCPU of that same guest or a thread idle in host mode.

Usage
-----
Requires patched OVMF [1] and QEMU [2] builds (unchanged from v2). Launch an SEV-SNP guest with ESMTP enabled on the sev-snp-guest object:

-object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,esmtp=on

ESMTP is opt-in because it carries a performance cost as VMRUN stalls until the sibling runs work from a trusted vCPU or is in host idle.

The guest reports the feature in dmesg among the SNP feature names:

  # dmesg | grep -i SEV
  ... SEV-SNP ... ESMTProt ...

Empirical test
--------------
* Identify siblings via:
cat /sys/devices/system/cpu/cpuX/topology/thread_siblings_list
* Pin the guest on the siblings
* Spawn a load in the guest e.g. via stress-ng --cpu 2 for SMT=2. Expect the guest utilization % for both sibling CPUs to be at 100% as the vCPU siblings are deemed trusted
* Spawn a load in the host latched onto one of the siblings. E.g. taskset -C X stress-ng --cpu 1
* Expect CPU X's utilization to be shared between host and guest %. Also expect drop in CPU utilization on the thread Sibling CPU as when the host task runs the guest will be forced idle.

Patches based on kvm/next

v4:
* Fix conflict of reserved bits introduced by PML support in vmcb_control_area

Response to Sashiko AI:
The EVENTINJ field is cleared unconditionally. so after a VMRUN, even if the VALID bit wasn't set, the field would be cleared. so I don't think we can hit the scenario that Sashiko is referring to.

v3: https://lore.kernel.org/kvm/[email protected]
* Collected Reviewed-by tags - Tom
* Reword esmtp_timeout_ns description - Tom
* Use sev_status to determine SNP support for guest as well - Tom
* Convert esmtp_timeout_ns to u32 instead of u64 to avoid a #DE error if the division extends over 64 bits. - Sashiko

Response to Sashiko AI
* Possibility of a stale EVENTINJ to clobber a valid EXITINTINFO here in svm_complete_interrupts():
- Today we make check only on a non-zero EVENTINJ rather than a VALID one since that check on exitintinfo is made on it anyways later within the function.
- AFAIU, it is not possible to have leftover events from L1 injected into L2 wihout the valid bit set.
- Only an L1 that does so deliberately can possibly trigger this and even then the impact is limited to that L1's L2.
- I could add an additional control->event_inj & SVM_EXITINTINFO_VALID check if is really a case that can be reached in reality but keeping it off for now.
* Not syncing msr-index changes since several bits apart from ESMTP are also changed and perf tooling maintainers generally sync that. However, if needed I drop in a patch that syncs the MSRs too.

v2: https://lore.kernel.org/kvm/[email protected]/
* Move idle wakeup ICR programming to svm_enable_virtualization_cpu() instead of sev_hardware_setup() - Sashiko
* Remove cond_sched() in ESMTP exit paths - Sashiko
* Add a VMSA builing of ESMTP fields for hyperv - Sashiko
* Add ESMTP to SNP_FEATURES_IMPL and SNP_FEATURES_IMPL_REQ - Local Claude Sashiko instance
* Cover hotplug CPUs / SMT changes by programming the ICR for all CPUs
- local Claude Sashiko instance
* Add esmtp timeout documentation to kernel paramters
* Collected Acked-by tag - Boris

v1: https://lore.kernel.org/kvm/[email protected]

[1]: https://github.com/tianocore/edk2/pull/13128
[2]: https://lore.kernel.org/qemu-devel/[email protected]/

Pratik R. Sampat (4):
KVM: SVM: Re-queue events that were never injected
KVM: SVM: Add host support for Enhanced SMT Protection x86/sev: Add guest support for Enhanced SMT Protection x86/hyperv: Add guest support for Enhanced SMT Protection

 .../admin-guide/kernel-parameters.txt         | 19 ++++++++
 arch/x86/boot/compressed/sev.c                |  6 ++-
 arch/x86/coco/sev/core.c                      | 13 +++++
 arch/x86/hyperv/ivm.c                         | 11 +++++
 arch/x86/include/asm/cpufeatures.h            |  1 +
 arch/x86/include/asm/msr-index.h              |  5 +-
 arch/x86/include/asm/svm.h                    | 12 ++++-
 arch/x86/include/uapi/asm/svm.h               |  9 +++-
 arch/x86/kernel/cpu/scattered.c               |  1 +
 arch/x86/kvm/svm/sev.c                        | 48 ++++++++++++++++++-
 arch/x86/kvm/svm/svm.c                        | 41 ++++++++++++++--
 arch/x86/kvm/svm/svm.h                        |  2 +
 12 files changed, 157 insertions(+), 11 deletions(-)

2.43.0