On 7/13/20 6:45 PM, Sean Christopherson wrote: > This is all kinds of backwards. Virtualization being disabled in hardware > is very, very different than KVM not being loaded. One requires at the > very least a kernel reboot to change, the other does not. That's a very good point. It's a pretty slippery slope if we go trying to figure out at runtime what our vulnerabilities are. We could, for instance, claim that we're not vulnerable to Meltdown until we run non-root code, or something else equally silly. Let's stick to things which are at least static per reboot. Checking for X86_FEATURE_VMX or even CONFIG_KVM_INTEL seems like a good stopping point. "Could this kernel run a naughty guest?" If so, report "Vulnerable". It's the same as Meltdown: "Could this kernel run untrusted code?" If so, report "Vulnerable". I don't think we should care about random kernel modules flipping CR4 bits. They can do much more harm than expose a system to an issue like this. If we care about reporting mitigation status once that happens, maybe out-of-tree modules loads should just flip *all* these cpu bugs from Mitigated->Vulerable. :)
