KVM SVM(AMD) nested - disabled by default?
"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?
Paolo Bonzini
maintainerQuoted 11 lines · 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=1298244but "... 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
Quoted 12 lines · Paolo Bonzini
Quoted 9 lines · 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=1298244but "... I am *thinking* of changing it ..." ain't explanation, man.
Quoted 9 lines
Quoted 2 lines
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.
Paolo Bonzini
maintainerQuoted 24 lines · poma
Quoted 12 lines · Paolo Bonzini
Quoted 9 lines · 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=1298244but "... I am *thinking* of changing it ..." ain't explanation, man.
Quoted 9 lines
Quoted 2 lines
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
Quoted 6 lines
"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.txtSo 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
Quoted 32 lines · Paolo Bonzini
Quoted 29 lines · poma
Quoted 12 lines · Paolo Bonzini
Quoted 9 lines · 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=1298244but "... I am *thinking* of changing it ..." ain't explanation, man.
Quoted 9 lines
Quoted 2 lines
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
Quoted 9 lines
Quoted 1 line
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.
Quoted 32 lines · Paolo Bonzini
Quoted 29 lines · poma
Quoted 12 lines · Paolo Bonzini
Quoted 9 lines · 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=1298244but "... I am *thinking* of changing it ..." ain't explanation, man.
Quoted 9 lines
Quoted 2 lines
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
Quoted 8 lines
Quoted 1 line
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
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
Quoted 60 lines · Jidong Xiao
Quoted 32 lines · Paolo Bonzini
Quoted 29 lines · poma
Quoted 12 lines · Paolo Bonzini
Quoted 9 lines · 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=1298244but "... I am *thinking* of changing it ..." ain't explanation, man.
Quoted 9 lines
Quoted 2 lines
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.txtQuoted 8 lines
Quoted 1 line
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
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 9 lines · 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.
Thanks Andy, good to know that!
-Jidong
Quoted 61 lines · Jidong Xiao
Quoted 60 lines · Paolo Bonzini
Quoted 32 lines · poma
Quoted 29 lines · Paolo Bonzini
Quoted 12 lines · poma
Quoted 9 lines
"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=1298244but "... I am *thinking* of changing it ..." ain't explanation, man.
Quoted 9 lines
Quoted 2 lines
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.txtQuoted 8 lines
Quoted 1 line
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
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html