On Tue, Aug 16, 2016 at 12:03 AM, Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > On 08/16/2016 02:23 AM, Lars Bull wrote: > [...] > >> We've done the following work on this front: > [...] > > Thanks for doing this. Are the tests closed or public? Would it make > sense to also use these for others archslike s390/ppc (lets say with less > effort than a rewrite) or is this really x86-specific code? Unfortunately, both levels' fuzzers are pretty x86-specific. The L1 fuzzer specifically focuses on the VMCS and lives in vmx.c. It's a fairly simple fuzzer that has a list of VMCS control field addresses and sizes and just flips bits with a low probability on L2 exits. It could be made public. The L2 fuzzer is written in x86 assembly and unfortunately can't be made public at this time due to its dependencies, though we've discussed the possibility of pursuing this in the future. >> Our testing was focused primarily on security of the host from both >> guest levels rather than the security of L1 and did not check for >> correctness. We are fairly confident after this work that nested VMX >> doesn't present a significant increase in risk for the host. We're >> curious what the next steps should be in getting this considered >> production-ready. > > Are there any plans to do L2->L1 testing? If we cannot be sure that L2 > does not violate the integrity of L1, we certainly cannot enable > that by default. (to make it more obvious, would you buy a hypervisor > that provides a "give-me-root" interface for its guests. While we didn't focus on the security of L1 in this review, it was covered by Andy's code review. Our fuzzing coverage of this was minimal because our VMCS fuzzing causes the L1 guest to be unstable, though we may work on L1-targeted nested fuzzing and crash detection in the future. Having nested VMX enabled by default is useful, but not as important to us as the feature being considered production-ready. -- 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
