Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753126AbdHOCvN (ORCPT ); Mon, 14 Aug 2017 22:51:13 -0400 Received: from gate.crashing.org ([63.228.1.57]:54487 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752718AbdHOCvL (ORCPT ); Mon, 14 Aug 2017 22:51:11 -0400 Message-ID: <1502760820.4493.40.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 , Robin Murphy Cc: 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 11:33:40 +1000 In-Reply-To: <59924B85.5040405@intel.com> References: <20170807072548.3023-1-aik@ozlabs.ru> <8f5f7b82-3c10-7f39-b587-db4c4424f04c@ozlabs.ru> <59924B85.5040405@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: 1907 Lines: 45 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. The table obfuscating in qemu is only useful as an insecure way of "making things sort-of-work" for HW that doesnt have proper remapping or filtering. On pseries we don't have that problem because: 1) Our hypervisor (which is qemu) provide the DMA address for MSIs/X so there is no need for "magic remapping" to give the guest a value that works. 2) Our HW (configured by VFIO/KVM) filters which device can DMA to what address (including which MSIs/X) thus even if the guest doesn't use the address passed and messes around, it can only shoot itself in the foot. So all we need is a way to tell qemu to stop doing that filtering on our platform. This is *one bit* of information, it's taken 3 years of arguments and we still don't have a solution. In the meantime, workloads *are* being hurt by significant performance degradation due to the MSI-X table sharing a 64K page (our page size) with other MMIOs. Yay ! Ben.