From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MxHnD-0003OT-Ut for qemu-devel@nongnu.org; Mon, 12 Oct 2009 06:06:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MxHn9-0003Nm-16 for qemu-devel@nongnu.org; Mon, 12 Oct 2009 06:06:15 -0400 Received: from [199.232.76.173] (port=45654 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MxHn8-0003Nj-Ne for qemu-devel@nongnu.org; Mon, 12 Oct 2009 06:06:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27755) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MxHn8-0005O7-3O for qemu-devel@nongnu.org; Mon, 12 Oct 2009 06:06:10 -0400 Date: Mon, 12 Oct 2009 12:06:06 +0200 From: Gleb Natapov Message-ID: <20091012100606.GD16702@redhat.com> References: <1255287547-28329-1-git-send-email-gleb@redhat.com> <1255287547-28329-4-git-send-email-gleb@redhat.com> <20091011214820.GB6411@redhat.com> <20091012064433.GR16702@redhat.com> <20091012071052.GA10741@redhat.com> <20091012072202.GU16702@redhat.com> <20091012081314.GB10741@redhat.com> <20091012084858.GY16702@redhat.com> <20091012094335.GC10741@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091012094335.GC10741@redhat.com> Subject: [Qemu-devel] Re: [PATCH 4/5] Make MMIO address page aligned in guest. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: kevin@koconnor.net, qemu-devel@nongnu.org On Mon, Oct 12, 2009 at 11:43:35AM +0200, Michael S. Tsirkin wrote: > > > Try hot-plugging the device instead of have it present on boot. > > > Patching BIOS won't help then, will it? So my question is, if we need > > > to handle this in qemu, is it worth it to do it in kvm as well? > > > > > It depend how linux assign mmio address to hot pluggable devices. How > > can you be sure a device driver continue working if you'll misrepresent > > BAR size BTW? > > Yes, this adds yet another way for device to discover it's running in a > VM, so this might break some drivers. If we see many of these in > practice, we can try adding a PCI-to-PCI bridge with some dummy devices > behind it to the picture, to increase the chances to get a dedicated > memory page. > Go ahead. But why all this churn instead of asking linux to align pci resources and do the same in a bios. > > > > > > As it stands this > > > > > > patch is in kvm's bios and is required for assigned devices to work > > > > > > for some devices, so moving to seabios without this patch will introduce > > > > > > a regression. > > > > > > > > > > I have a question here: if kvm maps a full physical page > > > > > into guest memory, while device only uses part of the page, > > > > > won't that mean that guest is granted access outside the > > > > > device, which it should not have? > > > > And how is real HW different? It maps a full physical page into OS > > > > memory even if BAR is smaller then page and grants OS access to > > > > unassigned mmio region. Access unassigned mmio region shouldn't cause > > > > any trouble, doesn't it? > > > > > > Unassigned - typically no, but there can be another device there, or a RAM > > > page. It is different on real hardware where OS has access to all RAM and all > > > devices, anyway. > > > > > > Here's an example from my laptop: > > > > > > 00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07) > > > Subsystem: Lenovo Device 20e6 > > > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- > > Latency: 0 > > > Interrupt: pin A routed to IRQ 11 > > > Region 0: Memory at fc226800 (64-bit, non-prefetchable) [size=16] > > > Capabilities: > > > > > > ... > > > > > > 00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03) (prog-if 01 [AHCI 1.0]) > > > Subsystem: Lenovo Device 20f8 > > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ > > > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- > > Latency: 0 > > > Interrupt: pin B routed to IRQ 28 > > > Region 0: I/O ports at 1c48 [size=8] > > > Region 1: I/O ports at 183c [size=4] > > > Region 2: I/O ports at 1c40 [size=8] > > > Region 3: I/O ports at 1838 [size=4] > > > Region 4: I/O ports at 1c20 [size=32] > > > Region 5: Memory at fc226000 (32-bit, non-prefetchable) [size=2K] > > > Capabilities: > > > Kernel driver in use: ahci > > > > > > In this setup, if you assign a page at address fc226000, for SATA, > > > I think that guest will be able to control Communication controller as well. > > Who configures BARs for assigned device guest or host? > > Host. Nice, device assignment is broken in one more way. > > > If host you can't safely passthrough one of those devices. > > Why not? > For the reason you stated. If you map fc226000-fc227000 to a guest it can control device at fc226800. > > But passthrough is not secure anyway since guest can DMA all over host > > memory. > > > That's why we only enable it with I/O mmu, right? > We do? Not sure about it. It is absolutely required if you want security of course, but not everyone care. > > > > > > > > Maybe the solution is to disable bypass for sub-page BARs and to > > > > > handle them in qemu, where we don't have alignment restrictions? > > > > > > > > > Making fast path go through qemu for assigned devices? May be remove > > > > this pass through crap from kvm to save us all from this misery then? > > > > > > Another option is for KVM to check these scenarious and deny assignment if > > > there's such an overlap. > > One more constrain for device assignment. Simple real life scenarios > > don't work for our users as it is. Adding more constrains will not help. > > For linux host, you can force resource alignment using a kernel > parameter. What do you suggest? Ignore this issue? > I suggest forcing resource alignment in a host using a kernel parameter if you care about security. -- Gleb.