Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752541AbdHOOtI (ORCPT ); Tue, 15 Aug 2017 10:49:08 -0400 Received: from smtp-out6.electric.net ([192.162.217.192]:55802 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750936AbdHOOtG (ORCPT ); Tue, 15 Aug 2017 10:49:06 -0400 From: David Laight To: "'Benjamin Herrenschmidt'" , Jike Song , Robin Murphy CC: Vlad Tsyrklevich , Neo Jia , "kvm@vger.kernel.org" , Eric Auger , Alexey Kardashevskiy , "David Woodhouse" , Joerg Roedel , "Kyle Mahlkuch" , Kirti Wankhede , "kvm-ppc@vger.kernel.org" , "iommu@lists.linux-foundation.org" , Yongji Xie , Alex Williamson , Mauricio Faria de Oliveira , Paul Mackerras , "Bjorn Helgaas" , Arvind Yadav , "linuxppc-dev@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" , David Gibson Subject: RE: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table Thread-Topic: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table Thread-Index: AQHTFWbaY9aWZpUct0u3iOg3LSbxxKKFfyew Date: Tue, 15 Aug 2017 14:48:52 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD0055E4A@AcuExch.aculab.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> In-Reply-To: <1502760820.4493.40.camel@kernel.crashing.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 156.67.243.126 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v7FEnDD4018855 Content-Length: 1026 Lines: 22 From: Benjamin Herrenschmidt > Sent: 15 August 2017 02:34 > 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 :-) Indeed, we have an FPGA based PCIe card where the MSI-X table is just a piece of PCIe accessible memory. The device driver has to read the MSI-X table and write the address+data values to other registers which are then used to raise the interrupt. (Ok, I've written a better interrupt generator so we don't do that any more.) David