Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1395121
| From | Yongji Xie <xyjxie@linux.vnet.ibm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported |
| Date | 2016-05-05 15:30 +0200 |
| Message-ID | <rvrvT-MH-61@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <ruD61-3HL-9@gated-at.bofh.it> <rvnVf-5Rb-7@gated-at.bofh.it> <rvoeD-626-17@gated-at.bofh.it> <rvpX3-7DD-7@gated-at.bofh.it> <rvqq6-8en-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 2016/5/5 20:15, Tian, Kevin wrote: >> From: Yongji Xie [mailto:xyjxie@linux.vnet.ibm.com] >> Sent: Thursday, May 05, 2016 7:43 PM >> >> Hi David and Kevin, >> >> On 2016/5/5 17:54, David Laight wrote: >> >>> From: Tian, Kevin >>>> Sent: 05 May 2016 10:37 >>> ... >>>>> Acutually, we are not aimed at accessing MSI-X table from >>>>> guest. So I think it's safe to passthrough MSI-X table if we >>>>> can make sure guest kernel would not touch MSI-X table in >>>>> normal code path such as para-virtualized guest kernel on PPC64. >>>>> >>>> Then how do you prevent malicious guest kernel accessing it? >>> Or a malicious guest driver for an ethernet card setting up >>> the receive buffer ring to contain a single word entry that >>> contains the address associated with an MSI-X interrupt and >>> then using a loopback mode to cause a specific packet be >>> received that writes the required word through that address. >>> >>> Remember the PCIe cycle for an interrupt is a normal memory write >>> cycle. >>> >>> David >>> >> If we have enough permission to load a malicious driver or >> kernel, we can easily break the guest without exposed >> MSI-X table. >> >> I think it should be safe to expose MSI-X table if we can >> make sure that malicious guest driver/kernel can't use >> the MSI-X table to break other guest or host. The >> capability of IRQ remapping could provide this >> kind of protection. >> > With IRQ remapping it doesn't mean you can pass through MSI-X > structure to guest. I know actual IRQ remapping might be platform > specific, but at least for Intel VT-d specification, MSI-X entry must > be configured with a remappable format by host kernel which > contains an index into IRQ remapping table. The index will find a > IRQ remapping entry which controls interrupt routing for a specific > device. If you allow a malicious program random index into MSI-X > entry of assigned device, the hole is obvious... Do you mean we can trigger MSIs that correspond to interrupt IDs of other devices by writing to MSI-X table although IRQ remapping is enabled? On PPC64, there is a mapping between MSIs and PE num which can be used to identify a PCI device on PHB. So the hardware can ensure a given pci device can only shoot the MSIs assigned for it. Isn't there a similar mapping in IRQ remapping table on Intel. Thanks, Yongji > Above might make sense only for a IRQ remapping implementation > which doesn't rely on extended MSI-X format (e.g. simply based on > BDF). If that's the case for PPC, then you should build MSI-X > passthrough based on this fact instead of general IRQ remapping > enabled or not. > > Thanks > Kevin
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported "Tian, Kevin" <kevin.tian@intel.com> - 2016-05-03 07:40 +0200
Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported Yongji Xie <xyjxie@linux.vnet.ibm.com> - 2016-05-03 08:10 +0200
RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported "Tian, Kevin" <kevin.tian@intel.com> - 2016-05-03 08:30 +0200
Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported Yongji Xie <xyjxie@linux.vnet.ibm.com> - 2016-05-03 09:40 +0200
RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported "Tian, Kevin" <kevin.tian@intel.com> - 2016-05-05 11:40 +0200
RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported David Laight <David.Laight@ACULAB.COM> - 2016-05-05 12:00 +0200
Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported Yongji Xie <xyjxie@linux.vnet.ibm.com> - 2016-05-05 13:50 +0200
RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported "Tian, Kevin" <kevin.tian@intel.com> - 2016-05-05 14:20 +0200
Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported Yongji Xie <xyjxie@linux.vnet.ibm.com> - 2016-05-05 15:30 +0200
Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported Alex Williamson <alex.williamson@redhat.com> - 2016-05-05 17:10 +0200
Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported Alexey Kardashevskiy <aik@ozlabs.ru> - 2016-05-06 08:40 +0200
Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported Alex Williamson <alex.williamson@redhat.com> - 2016-05-06 19:00 +0200
RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported "Tian, Kevin" <kevin.tian@intel.com> - 2016-05-11 08:30 +0200
Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported Alex Williamson <alex.williamson@redhat.com> - 2016-05-11 18:00 +0200
RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported "Tian, Kevin" <kevin.tian@intel.com> - 2016-05-12 03:30 +0200
Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported Alex Williamson <alex.williamson@redhat.com> - 2016-05-12 04:30 +0200
RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported "Tian, Kevin" <kevin.tian@intel.com> - 2016-05-12 07:00 +0200
Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported Yongji Xie <xyjxie@linux.vnet.ibm.com> - 2016-05-05 13:50 +0200
csiph-web