On Wed, Jul 15, 2020 at 10:18:20AM -0700, Pawan Gupta wrote:
> On Tue, Jul 14, 2020 at 05:51:30PM -0700, Sean Christopherson wrote:
> > On Tue, Jul 14, 2020 at 02:20:59PM -0700, Dave Hansen wrote:
> > > On 7/14/20 2:04 PM, Pawan Gupta wrote:
> > > >> I see three inputs and four possible states
On Tue, Jul 14, 2020 at 05:51:30PM -0700, Sean Christopherson wrote:
> On Tue, Jul 14, 2020 at 02:20:59PM -0700, Dave Hansen wrote:
> > On 7/14/20 2:04 PM, Pawan Gupta wrote:
> > >> I see three inputs and four possible states (sorry for the ugly table,
> > >> it was this or a spreadsheet :):
> >
On 7/14/20 5:51 PM, Sean Christopherson wrote:
> To do the above table, KVM will also need to update
> itlb_multihit_kvm_mitigation
> when it is unloaded, which seems rather silly. That's partly why I suggested
> keying off CR4.VMXE as it doesn't require poking directly into KVM. E.g. the
>
On Tue, Jul 14, 2020 at 02:20:59PM -0700, Dave Hansen wrote:
> On 7/14/20 2:04 PM, Pawan Gupta wrote:
> >> I see three inputs and four possible states (sorry for the ugly table,
> >> it was this or a spreadsheet :):
> >>
> >> X86_FEATURE_VMXCONFIG_KVM_*hpage split ResultReason
>
On 7/14/20 2:04 PM, Pawan Gupta wrote:
>> 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 ResultReason
>> N x xNot Affected No
On Tue, Jul 14, 2020 at 12:54:26PM -0700, Dave Hansen wrote:
> 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
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
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
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
On Mon, Jul 13, 2020 at 06:18:54PM -0700, Pawan Gupta wrote:
> On systems that have virtualization disabled or KVM module is not
> loaded, sysfs mitigation state of X86_BUG_ITLB_MULTIHIT is reported
> incorrectly as:
>
> $ cat /sys/devices/system/cpu/vulnerabilities/itlb_multihit
> KVM:
On systems that have virtualization disabled or KVM module is not
loaded, sysfs mitigation state of X86_BUG_ITLB_MULTIHIT is reported
incorrectly as:
$ cat /sys/devices/system/cpu/vulnerabilities/itlb_multihit
KVM: Vulnerable
System is not vulnerable to DoS attack from a rogue guest when:
-
11 matches
Mail list logo
