On 7/14/20 12:17 PM, Pawan Gupta wrote: > On Tue, Jul 14, 2020 at 07:57:53AM -0700, Dave Hansen wrote: >> 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". > > Thanks, These are good inputs. So what I need to add is a boot time > check for VMX feature and report "Vulnerable" or "Not > affected(VMX disabled)". > > Are you suggesting to not change the reporting when KVM deploys the > "Split huge pages" mitigation? Is this because VMX can still be used by > other VMMs? > > The current mitigation reporting is very specific to KVM: > > - "KVM: Vulnerable" > - "KVM: Mitigation: Split huge pages" > > As the kernel doesn't know about the mitigation state of out-of-tree > VMMs can we add VMX reporting to always say vulnerable when VMX is > enabled: > > - "VMX: Vulnerable, KVM: Vulnerable" > - "VMX: Vulnerable, KVM: Mitigation: Split huge pages" > > And if VMX is disabled report: > > - "VMX: Not affected(VMX disabled)" I see three inputs and four possible states (sorry for the ugly table, it was this or a spreadsheet :): X86_FEATURE_VMX CONFIG_KVM_* hpage split Result Reason N x x Not Affected No VMX Y N x Not affected No KVM Y Y Y Mitigated hpage split Y Y N Vulnerable I don't think we should worry about out-of-tree VMX.
