On 10/19/2015 10:47 AM, Dmitry Vyukov wrote: >> Right, the memory areas that are accessed both by the hypervisor and the guest >> > should be treated as untrusted input, but the hypervisor is supposed to validate >> > the input carefully before using it - so I'm not sure how data races would >> > introduce anything new that we didn't catch during validation. > > One possibility would be: if result of a racy read is passed to guest, > that can leak arbitrary host data into guest. Does not sound good. > Also, without usage of proper atomic operations, it is basically > impossible to verify untrusted data, as it can be changing under your > feet. And storing data into a local variable does not prevent the data > from changing. What's missing here is that the guest doesn't directly read/write the memory: every time it accesses a memory that is shared with the host it will trigger an exit, which will stop the vcpu thread that made the access and kernel side kvm will pass the hypervisor the value the guest wrote (or the memory address it attempted to read). The value/address can't change under us in that scenario. > There are also some data races with free(), it does not looks good at all. I definitely agree there are quite a few real bugs there :) Thanks, Sasha -- 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
