linux-kernel - RE: [RFC PATCH] iommu/vt-d: Exclude known RMRRs from reserved ranges

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: <5FC3163CFD30C246ABAA99954A238FA83870DFE9@FRAEML521-MBX.china.huawei.com>
Date:   Tue, 3 Jul 2018 10:46:28 +0000
From:   Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>
To:     "Tian, Kevin" <kevin.tian@...el.com>,
        Alex Williamson <alex.williamson@...hat.com>
CC:     "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH] iommu/vt-d: Exclude known RMRRs from reserved ranges

Hi Alex,

> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@...el.com]
> Sent: 08 June 2018 03:56
> To: Alex Williamson <alex.williamson@...hat.com>
> Cc: dwmw2@...radead.org; iommu@...ts.linux-foundation.org;
> kvm@...r.kernel.org; linux-kernel@...r.kernel.org; Shameerali Kolothum
> Thodi <shameerali.kolothum.thodi@...wei.com>
> Subject: RE: [RFC PATCH] iommu/vt-d: Exclude known RMRRs from reserved
> ranges
> 
> > From: Alex Williamson [mailto:alex.williamson@...hat.com]
> > Sent: Thursday, June 7, 2018 11:02 PM
> >
> > On Wed, 6 Jun 2018 05:29:58 +0000
> > "Tian, Kevin" <kevin.tian@...el.com> wrote:
> >
> > > > From: Alex Williamson
> > > > Sent: Wednesday, June 6, 2018 3:07 AM
> > > >
> > > > device_is_rmrr_locked() allows graphics and USB devices to participate
> > > > in the IOMMU API despite, and ignoring their RMRR association,
> > however
> > > > intel_iommu_get_resv_regions() still includes the RMRRs as unavailable
> > > > IOVA space for the device.  Are we ignoring the RMRR for these devices
> > > > or are we not?  If vfio starts consuming reserved regions, perhaps we
> > > > no longer need to consider devices with RMRRs excluded from the
> > IOMMU
> > > > API interface, but we have a transitional problem that these allowed
> > > > devices still impose incompatible IOVA restrictions per the reserved
> > > > region reporting.  Dive further down the rabbit hole by also ignoring
> > > > RMRRs for "known" devices in the reserved region reporting.
> > >
> > > intel_iommu_get_resv_regions is used not just for IOMMU API. I'm
> > > afraid doing so will make RMRR completely ignored, even in normal
> > > DMA API path...
> >
> > Well, I'm a bit stuck then, we have existing IOMMU API users that
> > ignore these ranges and in fact conflict with these ranges blocking us
> > from restricting mappings within these ranges.  My impression is that
> > IOMMU reserved ranges should only be ranges which have some
> > fundamental
> > limitation in the IOMMU, not simply mappings for which firmware has
> > requested an identity mapped range.  The latter should simply be a
> > pre-allocation of the IOVA space, for the cases where we choose to
> > honor the RMRR.  Thanks,
> >
> 
> Then possibly need introduce a different interface for pre-allocation
> scenario, if above definition of reserved ranges is agreed. Currently
> two categories are both called reserved resources, e.g. IOMMU_RESV
> _DIRECT for rmrr and IOMMU_RESV_MSI for MSI...

Sorry, but I just thought of checking on the future plans/directions for solving
this issue(Unfortunately vfio iova list series depends on this).

Please let me know if there is any plans for a v2 soon.

Much appreciated,
Shameer