linux-kernel - Re: [PATCH v6 0/7] vfio/type1: Add support for valid iova list management

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180605110304.33e14b0d@w520.home>
Date:   Tue, 5 Jun 2018 11:03:04 -0600
From:   Alex Williamson <alex.williamson@...hat.com>
To:     Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>
Cc:     "eric.auger@...hat.com" <eric.auger@...hat.com>,
        "pmorel@...ux.vnet.ibm.com" <pmorel@...ux.vnet.ibm.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        Linuxarm <linuxarm@...wei.com>,
        "John Garry" <john.garry@...wei.com>,
        "xuwei (O)" <xuwei5@...wei.com>, Joerg Roedel <joro@...tes.org>,
        David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH v6 0/7] vfio/type1: Add support for valid iova list
 management

[Cc +dwmw2]

On Fri, 25 May 2018 14:54:08 -0600
Alex Williamson <alex.williamson@...hat.com> wrote:

> On Fri, 25 May 2018 08:45:36 +0000
> Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com> wrote:
> 
> > Yes, the above changes related to list empty cases looks fine to me.   
> 
> Thanks Shameer, applied to my next branch with the discussed fixes for
> v4.18 (modulo patch 4/7 which Joerg already pushed for v4.17).  Thanks,

Hi Shameer,

We're still hitting issues with this.  VT-d marks reserved regions for
any RMRR ranges, which are IOVA ranges that the BIOS requests to be
identity mapped for a device.  These are indicated by these sorts of
log entries on boot:

 DMAR: Setting RMRR:
 DMAR: Setting identity map for device 0000:00:02.0 [0xbf800000 - 0xcf9fffff]
 DMAR: Setting identity map for device 0000:00:1a.0 [0xbe8d1000 - 0xbe8dffff]
 DMAR: Setting identity map for device 0000:00:1d.0 [0xbe8d1000 - 0xbe8dffff]

So while for an unaffected device, I see very usable ranges for QEMU,
such as:

	00: 0000000000000000 - 00000000fedfffff
	01: 00000000fef00000 - 01ffffffffffffff

If I try to assign the previously assignable 00:02.0 IGD graphics
device, I get:

	00: 0000000000000000 - 00000000bf7fffff
	01: 00000000cfa00000 - 00000000fedfffff
	02: 00000000fef00000 - 01ffffffffffffff

And we get a fault when QEMU tries the following mapping:

vfio_dma_map(0x55f790421a20, 0x100000, 0xbff00000, 0x7ff163f00000)

bff00000 clearly extends into the gap starting at bf800000.  VT-d is
rather split-brained about RMRRs, typically we'd exclude devices from
assignment at all for relying on RMRRs and these reserved ranges
would be a welcome mechanism to avoid conflicts with those ranges, but
for RMRR ranges covering IGD and USB devices we've decided that we
don't need to honor the RMRR (see device_is_rmrr_locked()), but it's
still listed as a reserved range and bites us here.

Unless we can get VT-d to exclude RMRRs from reserved regions where
we've already seen fit to allow the devices to participate in the IOMMU
API, this would introduce a functional regression for assignment of
these devices.  David, should we skip GFX and USB devices with RMRRs in
intel_iommu_get_resv_regions() just as we do in
device_is_rmrr_locked()?  Thanks,

Alex