On Mon, Oct 19, 2015 at 5:08 PM, Sasha Levin <sasha.levin@xxxxxxxxxx> wrote: > 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. But still: if result of a racy read is passed to guest, that can leak arbitrary host data into guest. -- 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
