From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [PATCH] uio_pci_generic does not export memory resources Date: Sat, 09 Jun 2012 10:55:36 -0600 Message-ID: <1339260936.26976.182.camel@ul30vt> References: <1339156616.3870.9.camel@blech> <20120608130351.GB1964@redhat.com> <4FD1FB49.3020905@siemens.com> <1339165009.26976.60.camel@ul30vt> <1339166867.3870.29.camel@blech> <4FD22552.6090609@01019freenet.de> <1339173706.26976.91.camel@ul30vt> <201206090928.q599SXSV003324@mail.maya.org> <1339253455.26976.165.camel@ul30vt> <4FD3790E.2010808@01019freenet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , "Michael S. Tsirkin" , kvm@vger.kernel.org To: Andreas Hartmann Return-path: Received: from mx1.redhat.com ([209.132.183.28]:47125 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751806Ab2FIQzp (ORCPT ); Sat, 9 Jun 2012 12:55:45 -0400 In-Reply-To: <4FD3790E.2010808@01019freenet.de> Sender: kvm-owner@vger.kernel.org List-ID: On Sat, 2012-06-09 at 18:25 +0200, Andreas Hartmann wrote: > Alex Williamson wrote: > > On Sat, 2012-06-09 at 11:28 +0200, Andreas Hartmann wrote: > > [...] > > >> What's the risk of this patch? Machine crash? Data loss for an active > >> file in an application? Complete filesystem damage? The latter would be > >> worse. > > > > What we're trying to prevent by testing whether devices support ACS is > > peer-to-peer transactions that would not be translated via the IOMMU. > > For instance, imagine if your WLAN controller behind 14.4 does a DMA > > write to an address that happens to be within the MMIO resources of > > device 14.2, the audio device. > > Why should it do that intentionally - I can't see any reason. Remains > unintentionally. But that's already enough :-) . We don't know the internal design of multifunction devices. > > Instead of the transaction going up to > > the IOMMU and resulting in a memory write, internal routing on device > > 14.x results in that transaction being redirected to the 14.2. So > > you're looking at potential data loss from the guest as well as > > corrupting device state in the host. > > My guest does have no data. Besides that, the VM can be easily backuped > before. > The corrupting device state probably is limited to the devices behind > the bridge. Correct? No, we're talking about the multifunction device here. A legacy PCI bus is always susceptible to this as it's a shared bus. Another device on the bus can claim the transaction. The IOMMU also only has visibility to the bridge devices, all devices behind it are masked. So the difference we're looking at is whether 14.4 is grouped with all the other devices on 14.x or not. Bus 6 will always be grouped with device 14.4. So then you have to consider what can happen if your guest that owns 14.4 and bus 6 can corrupt the state of device 14.2 and how that corrupted state could be propagated out to the host. > >>> Hmm, I wonder if we should make a kernel boot parameter that allows > >>> whitelisting some devices. I think it would have to taint the kernel > >>> but there's probably sufficient interest for usability vs > >>> supportability. > >> > >> Good idea. I would print an additional big fat warning of dataloss / > >> filesystem damage / crash if this could be the case. > > > > Well, outlining the risk above makes me a little more nervous about > > making such a config option, even if it taints the kernel, available so > > easily... :^\ > > That's true, too. Anyway, out of curiosity, if the corruption of the > device states is limited to the devices behind the bridge, I'm going to > test it. I hope that a hardware damage isn't possible by that action. Hardware damage should not be possible, but the interactions would be between host and guest as noted above. Thanks, Alex