On 10/19/2015 10:24 AM, Dmitry Vyukov wrote: > On Mon, Oct 19, 2015 at 4:19 PM, Sasha Levin <sasha.le...@oracle.com> wrote: >> > On 10/19/2015 04:37 AM, Dmitry Vyukov wrote: >>>> >>> So in this case (and most of the other data race cases described in >>>> >>> the full log) it >>>>> >>> > seems like ThreadSanitizer is mixing with different accesses by the >>>>> >>> > guest to one underlying >>>>> >>> > block of memory on the host. >>>>> >>> > >>>>> >>> > Here, for example, T55 accesses the msix block of the virtio-net >>>>> >>> > PCI device, and T58 is accessing >>>>> >>> > the virtqueue exposed by that device. While they both get to the >>>>> >>> > same block of memory inside >>> >> I don't understand this. >>> >> Do you mean that this is a false positive? Or it is a real issue in lkvm? >> > >> > I suspect it's a false positive because ThreadSanitizer sees the memory as >> > one big >> > block, but the logic that makes sure we don't race here is within the >> > guest vm, which >> > ThreadSanitizer doesn't see. > > But isn't the task of a hypervisor to sandbox the guest OS and to not > trust it in any way, shape or form? What if the guest VM intentionally > omits the synchronization? Can it exploit the host?
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. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
