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