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] [day] [month] [year] [list]

Message-ID: <1530615159.13595.9.camel@infradead.org>
Date:   Tue, 03 Jul 2018 11:52:39 +0100
From:   David Woodhouse <dwmw2@...radead.org>
To:     Alex Williamson <alex.williamson@...hat.com>,
        "Tian, Kevin" <kevin.tian@...el.com>
Cc:     "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>,
        "shameerali.kolothum.thodi@...wei.com" 
        <shameerali.kolothum.thodi@...wei.com>
Subject: Re: [RFC PATCH] iommu/vt-d: Exclude known RMRRs from reserved
 ranges

On Thu, 2018-06-07 at 09:01 -0600, Alex Williamson wrote:
> 
> > 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,

Unfortunately, Intel likes to encourage vendors to do batshit insane
things in firmware, at runtime, using DMA.

Perhaps the way to handle this is for the device drivers to cancel any
RMRR for their devices, as they take it over. So USB and graphics
drivers would clear the corresponding RMRRs as they take ownership of
the device... but anything without a driver, or things like the SCSI
host controllers which know that there might be some HP insanity going
on in SMM in parallel with what they're doing, would not (and hence
would not be assignable, etc.).


Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)