CVE-2023-53663: KVM: nSVM: Check instead of asserting on nested TSC scaling support

In the Linux kernel, the following vulnerability has been resolved:

KVM: nSVM: Check instead of asserting on nested TSC scaling support

Check for nested TSC scaling support on nested SVM VMRUN instead of asserting that TSC scaling is exposed to L1 if L1's MSRAMD64TSCRATIO has diverged from KVM's default. Userspace can trigger the WARN at will by writing the MSR and then updating guest CPUID to hide the feature (modifying guest CPUID is allowed anytime before KVMRUN). E.g. hacking KVM's statetest selftest to do

vcpusetmsr(vcpu, MSRAMD64TSCRATIO, 0); vcpuclearcpuidfeature(vcpu, X86FEATURETSCRATEMSR);

after restoring state in a new VM+vCPU yields an endless supply of:

------------[ cut here ]------------ WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699 nestedvmcb02preparecontrol+0x3d6/0x3f0 [kvmamd] Call Trace: <TASK> entersvmguestmode+0x114/0x560 [kvmamd] nestedsvmvmrun+0x260/0x330 [kvmamd] vmruninterception+0x29/0x30 [kvmamd] svminvokeexithandler+0x35/0x100 [kvmamd] svmhandleexit+0xe7/0x180 [kvmamd] kvmarchvcpuioctlrun+0x1eab/0x2570 [kvm] kvmvcpuioctl+0x4c9/0x5b0 [kvm] sesysioctl+0x7a/0xc0 x64sysioctl+0x21/0x30 dosyscall64+0x41/0x90 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x45ca1b

Note, the nested #VMEXIT path has the same flaw, but needs a different fix and will be handled separately.