Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752824AbdHOFkH (ORCPT ); Tue, 15 Aug 2017 01:40:07 -0400 Received: from gate.crashing.org ([63.228.1.57]:60127 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751841AbdHOFkF (ORCPT ); Tue, 15 Aug 2017 01:40:05 -0400 Message-ID: <1502775480.4493.45.camel@kernel.crashing.org> Subject: Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table From: Benjamin Herrenschmidt To: Jike Song Cc: Robin Murphy , Alexey Kardashevskiy , linuxppc-dev@lists.ozlabs.org, David Gibson , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, Yongji Xie , Eric Auger , Kyle Mahlkuch , Alex Williamson , Bjorn Helgaas , Joerg Roedel , Arvind Yadav , David Woodhouse , Kirti Wankhede , Mauricio Faria de Oliveira , Neo Jia , Paul Mackerras , Vlad Tsyrklevich , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org Date: Tue, 15 Aug 2017 15:38:00 +1000 In-Reply-To: <599252B9.8030407@intel.com> References: <20170807072548.3023-1-aik@ozlabs.ru> <8f5f7b82-3c10-7f39-b587-db4c4424f04c@ozlabs.ru> <59924B85.5040405@intel.com> <1502760820.4493.40.camel@kernel.crashing.org> <599252B9.8030407@intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.4 (3.24.4-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2166 Lines: 48 On Tue, 2017-08-15 at 09:47 +0800, Jike Song wrote: > On 08/15/2017 09:33 AM, Benjamin Herrenschmidt wrote: > > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: > > > > Taking a step back, though, why does vfio-pci perform this check in the > > > > first place? If a malicious guest already has control of a device, any > > > > kind of interrupt spoofing it could do by fiddling with the MSI-X > > > > message address/data it could simply do with a DMA write anyway, so the > > > > security argument doesn't stand up in general (sure, not all PCIe > > > > devices may be capable of arbitrary DMA, but that seems like more of a > > > > tenuous security-by-obscurity angle to me). > > > > I tried to make that point for years, thanks for re-iterating it :-) > > > > > Hi Robin, > > > > > > DMA writes will be translated (thereby censored) by DMA Remapping hardware, > > > while MSI/MSI-X will not. Is this different for non-x86? > > > > There is no way your DMA remapping HW can differenciate. The only > > difference between a DMA write and an MSI is ... the address. So if I > > can make my device DMA to the MSI address range, I've defeated your > > security. > > I don't think with IRQ remapping enabled, you can make your device DMA to > MSI address, without being treated as an IRQ and remapped. If so, the IRQ > remapping hardware is simply broken :) You are mixing things here. Robin's point is that there is no security provided by the obfuscating of the MSI-X table by qemu because whatever qemu does to "filter" the MSI-X targer addresses can be worked around by making the device DMA wherever you want. None of what you say invalidates that basic fact. Now, as far as your remapping HW goes, either it filters interrupts or it doesn't. If it does then yes, it can't be spoofed, and thus you don't need the filtering of the table in qemu. If it doesn't, then the guest can spoof any interrupt using DMAs and whatever qemu does to filter the table is not going to fix it. Thus the point remains that the only value in qemu filtering the table is to enable already insecure use cases to work, without actually making them any more secure. Ben.