KVM SVM(AMD) nested - disabled by default?

KVM SVM(AMD) nested - disabled by default?

[poma]

"KVM: SVM: enable nested svm by default"
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/x86/kvm?id=4b6e4dc
"Nested SVM is (in my experience) stable enough to be enabled by default. So omit the requirement to pass a module parameter."

I tried to get an explanation of the eventual -default- change here:
https://bugzilla.redhat.com/show_bug.cgi?id=1298244

but "... I am *thinking* of changing it ..." ain't explanation, man.

I've tested "Nested SVM" myself and it works surprisingly well,
therefore what is the -actual- reason to switch it off by default?

Re: KVM SVM(AMD) nested - disabled by default?

[Paolo Bonzini]

On 23/01/2016 16:07, poma wrote:
> "KVM: SVM: enable nested svm by default"
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/x86/kvm?id=4b6e4dc
> "Nested SVM is (in my experience) stable enough to be enabled by default. So omit the requirement to pass a module parameter."
> 
> I tried to get an explanation of the eventual -default- change here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1298244
> 
> but "... I am *thinking* of changing it ..." ain't explanation, man.
> 
> I've tested "Nested SVM" myself and it works surprisingly well,
> therefore what is the -actual- reason to switch it off by default?

Neither nested VMX nor nested SVM have ever been audited for security;
they could have bugs that let a malicious guest escape L0.  In fact I
would be surprised if they don't. :(

Paolo

Re: KVM SVM(AMD) nested - disabled by default?

[poma]

On 23.01.2016 22:05, Paolo Bonzini wrote:
> 
> 
> On 23/01/2016 16:07, poma wrote:
>> "KVM: SVM: enable nested svm by default"
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/x86/kvm?id=4b6e4dc
>> "Nested SVM is (in my experience) stable enough to be enabled by default. So omit the requirement to pass a module parameter."
>>
>> I tried to get an explanation of the eventual -default- change here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1298244
>>
>> but "... I am *thinking* of changing it ..." ain't explanation, man.
>>
>> I've tested "Nested SVM" myself and it works surprisingly well,
>> therefore what is the -actual- reason to switch it off by default?
> 
> Neither nested VMX nor nested SVM have ever been audited for security;
> they could have bugs that let a malicious guest escape L0.  In fact I
> would be surprised if they don't. :(
> 
> Paolo
> 


"In nested virtualization, we have three levels: The host (KVM), which we call
L0, the guest hypervisor, which we call L1, and its nested guest, which we
call L2."
https://www.kernel.org/doc/Documentation/virtual/kvm/nested-vmx.txt

So as long as you don't nestle proprietary crap, no problemos.


Thanks for the concise explanations, man.

Re: KVM SVM(AMD) nested - disabled by default?

[Paolo Bonzini]

On 25/01/2016 19:31, poma wrote:
> On 23.01.2016 22:05, Paolo Bonzini wrote:
>>
>>
>> On 23/01/2016 16:07, poma wrote:
>>> "KVM: SVM: enable nested svm by default"
>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/x86/kvm?id=4b6e4dc
>>> "Nested SVM is (in my experience) stable enough to be enabled by default. So omit the requirement to pass a module parameter."
>>>
>>> I tried to get an explanation of the eventual -default- change here:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1298244
>>>
>>> but "... I am *thinking* of changing it ..." ain't explanation, man.
>>>
>>> I've tested "Nested SVM" myself and it works surprisingly well,
>>> therefore what is the -actual- reason to switch it off by default?
>>
>> Neither nested VMX nor nested SVM have ever been audited for security;
>> they could have bugs that let a malicious guest escape L0.  In fact I
>> would be surprised if they don't. :(
>>
>> Paolo
>>
> 
> 
> "In nested virtualization, we have three levels: The host (KVM), which we call
> L0, the guest hypervisor, which we call L1, and its nested guest, which we
> call L2."
> https://www.kernel.org/doc/Documentation/virtual/kvm/nested-vmx.txt
> 
> So as long as you don't nestle proprietary crap, no problemos.

Kind of.  Suppose you are a cloud provider, and you think offering
nested virtualization would be cool.  Now, a customer (who of course
controls the kernel running in your L1 VM) uses a vulnerability in KVM
to get out of his VM and attack the host.  Enorme problema.

Paolo

Re: KVM SVM(AMD) nested - disabled by default?

[poma]

On 26.01.2016 10:09, Paolo Bonzini wrote:
> 
> 
> On 25/01/2016 19:31, poma wrote:
>> On 23.01.2016 22:05, Paolo Bonzini wrote:
>>>
>>>
>>> On 23/01/2016 16:07, poma wrote:
>>>> "KVM: SVM: enable nested svm by default"
>>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/x86/kvm?id=4b6e4dc
>>>> "Nested SVM is (in my experience) stable enough to be enabled by default. So omit the requirement to pass a module parameter."
>>>>
>>>> I tried to get an explanation of the eventual -default- change here:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1298244
>>>>
>>>> but "... I am *thinking* of changing it ..." ain't explanation, man.
>>>>
>>>> I've tested "Nested SVM" myself and it works surprisingly well,
>>>> therefore what is the -actual- reason to switch it off by default?
>>>
>>> Neither nested VMX nor nested SVM have ever been audited for security;
>>> they could have bugs that let a malicious guest escape L0.  In fact I
>>> would be surprised if they don't. :(
>>>
>>> Paolo
>>>
>>
>>
>> "In nested virtualization, we have three levels: The host (KVM), which we call
>> L0, the guest hypervisor, which we call L1, and its nested guest, which we
>> call L2."
>> https://www.kernel.org/doc/Documentation/virtual/kvm/nested-vmx.txt
>>
>> So as long as you don't nestle proprietary crap, no problemos.
> 
> Kind of.  Suppose you are a cloud provider, and you think offering
> nested virtualization would be cool.  Now, a customer (who of course
> controls the kernel running in your L1 VM) uses a vulnerability in KVM
> to get out of his VM and attack the host.  Enorme problema.
> 
> Paolo
> 


Yeah, "closed source" is just a part of problemo.

Thanks for the extra explanation/example.

Re: KVM SVM(AMD) nested - disabled by default?

[Jidong Xiao]

On Tue, Jan 26, 2016 at 2:09 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 25/01/2016 19:31, poma wrote:
>> On 23.01.2016 22:05, Paolo Bonzini wrote:
>>>
>>>
>>> On 23/01/2016 16:07, poma wrote:
>>>> "KVM: SVM: enable nested svm by default"
>>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/x86/kvm?id=4b6e4dc
>>>> "Nested SVM is (in my experience) stable enough to be enabled by default. So omit the requirement to pass a module parameter."
>>>>
>>>> I tried to get an explanation of the eventual -default- change here:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1298244
>>>>
>>>> but "... I am *thinking* of changing it ..." ain't explanation, man.
>>>>
>>>> I've tested "Nested SVM" myself and it works surprisingly well,
>>>> therefore what is the -actual- reason to switch it off by default?
>>>
>>> Neither nested VMX nor nested SVM have ever been audited for security;
>>> they could have bugs that let a malicious guest escape L0.  In fact I
>>> would be surprised if they don't. :(
>>>
>>> Paolo
>>>
>>
>>
>> "In nested virtualization, we have three levels: The host (KVM), which we call
>> L0, the guest hypervisor, which we call L1, and its nested guest, which we
>> call L2."
>> https://www.kernel.org/doc/Documentation/virtual/kvm/nested-vmx.txt
>>
>> So as long as you don't nestle proprietary crap, no problemos.
>
> Kind of.  Suppose you are a cloud provider, and you think offering
> nested virtualization would be cool.  Now, a customer (who of course
> controls the kernel running in your L1 VM) uses a vulnerability in KVM
> to get out of his VM and attack the host.  Enorme problema.
>
> Paolo

Hi, Paolo,

Even if cloud providers don't use nested virtualization, as long as
there is "a vulnerability in KVM", it is still possible "to get out of
his VM and attack the host". You mentioned that "Neither nested VMX
nor nested SVM have ever been audited for security", so have this been
done for non-nested virtualization?

-Jidong

> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM SVM(AMD) nested - disabled by default?

[Andrew Honig]

My team at Google has spent roughly 2-3 person years of effort
security auditing KVM (both manually with code review and building
tools) and we've found a lot of issues over the years.  Also Nadav
Amit's work on the emulator was quite effective in finding security
bugs.

At this point, I don't know of anyone who's put any serious effort
into a security audit for nested vmx/svm.

On Tue, Jan 26, 2016 at 1:17 PM, Jidong Xiao <jidong.xiao@gmail.com> wrote:
> On Tue, Jan 26, 2016 at 2:09 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>>
>> On 25/01/2016 19:31, poma wrote:
>>> On 23.01.2016 22:05, Paolo Bonzini wrote:
>>>>
>>>>
>>>> On 23/01/2016 16:07, poma wrote:
>>>>> "KVM: SVM: enable nested svm by default"
>>>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/x86/kvm?id=4b6e4dc
>>>>> "Nested SVM is (in my experience) stable enough to be enabled by default. So omit the requirement to pass a module parameter."
>>>>>
>>>>> I tried to get an explanation of the eventual -default- change here:
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1298244
>>>>>
>>>>> but "... I am *thinking* of changing it ..." ain't explanation, man.
>>>>>
>>>>> I've tested "Nested SVM" myself and it works surprisingly well,
>>>>> therefore what is the -actual- reason to switch it off by default?
>>>>
>>>> Neither nested VMX nor nested SVM have ever been audited for security;
>>>> they could have bugs that let a malicious guest escape L0.  In fact I
>>>> would be surprised if they don't. :(
>>>>
>>>> Paolo
>>>>
>>>
>>>
>>> "In nested virtualization, we have three levels: The host (KVM), which we call
>>> L0, the guest hypervisor, which we call L1, and its nested guest, which we
>>> call L2."
>>> https://www.kernel.org/doc/Documentation/virtual/kvm/nested-vmx.txt
>>>
>>> So as long as you don't nestle proprietary crap, no problemos.
>>
>> Kind of.  Suppose you are a cloud provider, and you think offering
>> nested virtualization would be cool.  Now, a customer (who of course
>> controls the kernel running in your L1 VM) uses a vulnerability in KVM
>> to get out of his VM and attack the host.  Enorme problema.
>>
>> Paolo
>
> Hi, Paolo,
>
> Even if cloud providers don't use nested virtualization, as long as
> there is "a vulnerability in KVM", it is still possible "to get out of
> his VM and attack the host". You mentioned that "Neither nested VMX
> nor nested SVM have ever been audited for security", so have this been
> done for non-nested virtualization?
>
> -Jidong
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM SVM(AMD) nested - disabled by default?

[Jidong Xiao]

On Tue, Jan 26, 2016 at 2:28 PM, Andrew Honig <ahonig@google.com> wrote:
> My team at Google has spent roughly 2-3 person years of effort
> security auditing KVM (both manually with code review and building
> tools) and we've found a lot of issues over the years.  Also Nadav
> Amit's work on the emulator was quite effective in finding security
> bugs.
>
> At this point, I don't know of anyone who's put any serious effort
> into a security audit for nested vmx/svm.
>
Thanks Andy, good to know that!

-Jidong

> On Tue, Jan 26, 2016 at 1:17 PM, Jidong Xiao <jidong.xiao@gmail.com> wrote:
>> On Tue, Jan 26, 2016 at 2:09 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>
>>>
>>> On 25/01/2016 19:31, poma wrote:
>>>> On 23.01.2016 22:05, Paolo Bonzini wrote:
>>>>>
>>>>>
>>>>> On 23/01/2016 16:07, poma wrote:
>>>>>> "KVM: SVM: enable nested svm by default"
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/x86/kvm?id=4b6e4dc
>>>>>> "Nested SVM is (in my experience) stable enough to be enabled by default. So omit the requirement to pass a module parameter."
>>>>>>
>>>>>> I tried to get an explanation of the eventual -default- change here:
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1298244
>>>>>>
>>>>>> but "... I am *thinking* of changing it ..." ain't explanation, man.
>>>>>>
>>>>>> I've tested "Nested SVM" myself and it works surprisingly well,
>>>>>> therefore what is the -actual- reason to switch it off by default?
>>>>>
>>>>> Neither nested VMX nor nested SVM have ever been audited for security;
>>>>> they could have bugs that let a malicious guest escape L0.  In fact I
>>>>> would be surprised if they don't. :(
>>>>>
>>>>> Paolo
>>>>>
>>>>
>>>>
>>>> "In nested virtualization, we have three levels: The host (KVM), which we call
>>>> L0, the guest hypervisor, which we call L1, and its nested guest, which we
>>>> call L2."
>>>> https://www.kernel.org/doc/Documentation/virtual/kvm/nested-vmx.txt
>>>>
>>>> So as long as you don't nestle proprietary crap, no problemos.
>>>
>>> Kind of.  Suppose you are a cloud provider, and you think offering
>>> nested virtualization would be cool.  Now, a customer (who of course
>>> controls the kernel running in your L1 VM) uses a vulnerability in KVM
>>> to get out of his VM and attack the host.  Enorme problema.
>>>
>>> Paolo
>>
>> Hi, Paolo,
>>
>> Even if cloud providers don't use nested virtualization, as long as
>> there is "a vulnerability in KVM", it is still possible "to get out of
>> his VM and attack the host". You mentioned that "Neither nested VMX
>> nor nested SVM have ever been audited for security", so have this been
>> done for non-nested virtualization?
>>
>> -Jidong
>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html