On Tue, Jan 26, 2016 at 2:28 PM, Andrew Honig <ahonig@xxxxxxxxxx> 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@xxxxxxxxx> wrote: >> On Tue, Jan 26, 2016 at 2:09 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
