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.

Reply via email to