lkml.org 
[lkml]   [2022]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v5 09/14] PCI: portdrv: Suppress kernel DMA ownership auto-claiming
    On Tue, Jan 04, 2022 at 01:51:30PM -0600, Bjorn Helgaas wrote:
    > On Tue, Jan 04, 2022 at 03:26:14PM -0400, Jason Gunthorpe wrote:
    > > On Tue, Jan 04, 2022 at 11:06:31AM -0600, Bjorn Helgaas wrote:
    > >
    > > > > The existing vfio framework allows the portdrv driver to be bound
    > > > > to the bridge while its downstream devices are assigned to user space.
    > > >
    > > > I.e., the existing VFIO framework allows a switch to be in the same
    > > > IOMMU group as the devices below it, even though the switch has a
    > > > kernel driver and the other devices may have userspace drivers?
    > >
    > > Yes, this patch exists to maintain current VFIO behavior which has this
    > > same check.
    > >
    > > I belive the basis for VFIO doing this is that the these devices
    > > cannot do DMA, so don't care about the DMA API or the group->domain,
    > > and do not expose MMIO memory so do not care about the P2P attack.
    >
    > "These devices" means bridges, right? Not sure why we wouldn't care
    > about the P2P attack.

    Yes bridges. I said "I belive" because VFIO was changed to ignore
    bridges a long time ago and the security rational was a bit unclear in
    the commit.

    See 5f096b14d421 ("vfio: Whitelist PCI bridges")

    > PCIe switches use MSI or MSI-X for hotplug, PME, etc, so they do DMA
    > for that. Is that not relevant here?

    Alex's comment in the above commit notes about interrupts, but I think
    the answer today is that it does not matter.

    For platforms like x86 that keep interrupts and DMA seperate it
    works fine.

    For platforms that comingle the iommu_domain and interrupts (do some
    exist?) we expect the platform to do whatever is necessary at
    iommu_domain attach time to ensure interrupts continue to
    work. (AFAICT at least)

    In other words we don't have an API restriction to use
    iommu_device_use_dma_api() to use request_irq().

    So the main concern should be P2P attacks on bridge MMIO registers.

    > Is there something that *prohibits* a bridge from having
    > device-specific functionality including DMA?

    I'm not sure, I think not, but the 'Bus Master Enable' language does
    have a different definition for Type 1..

    However, it doesn't matter - the question here is not about what the
    device HW is capable of, but what does the kernel driver do. The
    portdrv does not use the DMA API, so that alone is half the
    requirement to skip the iommu_device_use_dma_api() call.

    Some future device-specific bridge driver that is able to issue the
    device-specific MMIO's and operate the DMA API should be coded to use
    iommu_device_use_dma_api(), probably by using a different
    device_driver for the bridge.

    > I know some bridges have device-specific BARs for performance counters
    > and the like.

    Yep.

    IMHO it is probably not so great as-is..

    However, this patch is just porting the status-quo of commit 5f09 into
    this new framework.

    What this new framework does allow is for portdrv to police itself. eg
    it could check if there is a MMIO BAR and call
    iommu_device_use_dma_api() out of caution. It could also have an
    allowance list of devices where we know hostile writes to the MMIO are
    known harmless.

    Without knowing more about what motivated 5f09 it is hard to say,
    other than it has been 7 years like this and nobody has complained
    yet :)

    Jason

    \
     
     \ /
      Last update: 2022-01-05 01:35    [W:3.823 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site