linux-kernel - Re: [PATCH] iommu/intel: Exclude devices using RMRRs from IOMMU API domains

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: <1400668716.13839.66.camel@shinybook.infradead.org>
Date:	Wed, 21 May 2014 11:38:36 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Alex Williamson <alex.williamson@...hat.com>
Cc:	iommu@...ts.linux-foundation.org, chegu_vinod@...com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iommu/intel: Exclude devices using RMRRs from IOMMU API
 domains

On Wed, 2014-05-14 at 13:27 -0600, Alex Williamson wrote:
> The user of the IOMMU API domain expects to have full control of
> the IOVA space for the domain.  RMRRs are fundamentally incompatible
> with that idea.  We can neither map the RMRR into the IOMMU API
> domain, nor can we guarantee that the device won't continue DMA with
> the area described by the RMRR as part of the new domain.  Therefore
> we must prevent such devices from being used by the IOMMU API.

Ick, ick, ick. The more the ramifications of RMRRs become apparent, the
more I wish we'd just done the Right Thing™ and declared that firmware
SHALL NOT leave any device doing (IOMMU-visible) DMA after the OS takes
over. That way, if they wanted this kind of abomination then they'd have
to come up with a way of doing it differently. Hell, can't you do PCIe
transactions which claim to be already translated, and thus just bypass
the IOMMU?

OK, rant over... 

Why can't we map the RMRR into the IOMMU API domain? If we're setting up
a VM guest, that basically means we'd want to poke a hole in its memory
map and mark the RMRR-afflicted range as reserved or absent. It's
horrible, but *everything* about RMRRs is horrible. It's not impossible,
and it would allow us to give these devices away to guests. Don't we
sometimes *have* devices that we want to give to guests, that are
afflicted with RMRRs?

There are discussions about RMRRs being (ab)used for more than their
existing brain-damaged purpose. Where we have a peripheral device that
will (mis)interpret certain address ranges as "local" rather than
forwarding transactions up towards main memory, we need to ensure that
such ranges are never used as virtual addresses. This has largely been
an invisible problem until we found a device where the affected range
matched the IOVA our DMA API uses by default. Using an RMRR has been
proposed as a simple way to achieve that... which means that you end up
not being able to assign *those* devices to IOMMU domains either.

I do suspect it's going to lead to complaints... but I'm just not sure I
can bring myself to care. Sane designs don't require RMRRs. If someone
comes to me and complains that their HP storage controller or whatever
can't be assigned to a guest, I'm quite prepared to tell them to replace
it with something non-broken. Will you back me up when it happens?

-- 
dwmw2

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