linux-kernel - Re: Summary of LPC guest MSI discussion in Santa Fe

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 11 Nov 2016 12:19:44 +0100
From:   Joerg Roedel <joro@...tes.org>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     Auger Eric <eric.auger@...hat.com>,
        Will Deacon <will.deacon@....com>, drjones@...hat.com,
        Christoffer Dall <christoffer.dall@...aro.org>,
        jason@...edaemon.net, kvm@...r.kernel.org, marc.zyngier@....com,
        benh@...nel.crashing.org, punit.agrawal@....com,
        linux-kernel@...r.kernel.org, diana.craciun@....com,
        iommu@...ts.linux-foundation.org, pranav.sawargaonkar@...il.com,
        arnd@...db.de, dwmw@...zon.co.uk, jcm@...hat.com,
        Don Dutile <ddutile@...hat.com>, tglx@...utronix.de,
        robin.murphy@....com, linux-arm-kernel@...ts.infradead.org,
        eric.auger.pro@...il.com
Subject: Re: Summary of LPC guest MSI discussion in Santa Fe

On Thu, Nov 10, 2016 at 10:46:01AM -0700, Alex Williamson wrote:
> In the case of x86, we know that DMA mappings overlapping the MSI
> doorbells won't be translated correctly, it's not a valid mapping for
> that range, and therefore the iommu driver backing the IOMMU API
> should describe that reserved range and reject mappings to it.

The drivers actually allow mappings to the MSI region via the IOMMU-API,
and I think it should stay this way also for other reserved ranges.
Address space management is done by the IOMMU-API user already (and has
to be done there nowadays), be it a DMA-API implementation which just
reserves these regions in its address space allocator or be it VFIO with
QEMU, which don't map RAM there anyway. So there is no point of checking
this again in the IOMMU drivers and we can keep that out of the
mapping/unmapping fast-path.

> For PCI devices userspace can examine the topology of the iommu group
> and exclude MMIO ranges of peer devices based on the BARs, which are
> exposed in various places, pci-sysfs as well as /proc/iomem.  For
> non-PCI or MSI controllers... ???

Right, the hardware resources can be examined. But maybe this can be
extended to also cover RMRR ranges? Then we would be able to assign
devices with RMRR mappings to guests.

	Joerg