From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: sanitizing kvmtool Date: Mon, 19 Oct 2015 10:35:51 -0400 Message-ID: <5624FFC7.2010301@oracle.com> References: <5622583D.2060006@oracle.com> <5624FBF4.20201@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Sasha Levin , Pekka Enberg , Asias He , penberg@cs.helsinki.fi, Cyrill Gorcunov , Will Deacon , andre.przywara@arm.com, matt@ozlabs.org, laijs@cn.fujitsu.com, Michael Ellerman , Prasad Joshi , marc.zyngier@arm.com, "Aneesh Kumar K.V" , mingo@elte.hu, gorcunov@openvz.org, andreas.herrmann@caviumnetworks.com, kvm@vger.kernel.org, Kostya Serebryany , Evgenii Stepanov , Alexey Samsonov , Alexander Potapenko To: Dmitry Vyukov Return-path: Received: from aserp1040.oracle.com ([141.146.126.69]:35711 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751642AbbJSOgl (ORCPT ); Mon, 19 Oct 2015 10:36:41 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 10/19/2015 10:24 AM, Dmitry Vyukov wrote: > On Mon, Oct 19, 2015 at 4:19 PM, Sasha Levin 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