linux-kernel - Re: [PATCH 2/2] iommu: dmar -- reserve mmio space used by IOMMU

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: <1338849430.10884.288.camel@shinybook.infradead.org>
Date:	Mon, 04 Jun 2012 23:37:10 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Donald Dutile <ddutile@...hat.com>
Cc:	iommu@...ts.linux-foundation.org, mingo@...e.hu,
	linux-kernel@...r.kernel.org, chrisw@...hat.com,
	suresh.b.siddha@...el.com
Subject: Re: [PATCH 2/2] iommu: dmar -- reserve mmio space used by IOMMU

On Mon, 2012-06-04 at 17:29 -0400, Donald Dutile wrote:
> Intel-iommu initialization doesn't currently reserve the memory used
> for the IOMMU registers. This can allow the pci resource allocator
> to assign a device BAR to the same address as the IOMMU registers.
> This can cause some not so nice side affects when the driver
> ioremap's that region.

s/affect/effect/

And surely this can happen even when IOMMU support is compiled out of
the kernel. Shouldn't the BIOS be *telling* us that this region is
unavailable for PCI resource allocation (or anything else, for that
matter)?

If the BIOS *doesn't* do that, then I believe this should be
WARN_TAINT_ONCE(…TAINT_FIRMWARE_WORKAROUND…) like other BIOS problems
that we have discovered.

And we should probably do it based on the actual chipset registers, not
the DMAR tables (which the BIOS has also been known to lie about).

-- 
dwmw2

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