linux-kernel - Re: [PATCH v11 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel

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]

Date:	Mon, 8 Jun 2015 18:13:15 +0200
From:	Joerg Roedel <joro@...tes.org>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	bhe@...hat.com, tom.vaden@...com, rwright@...com,
	linux-pci@...r.kernel.org, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, lisa.mitchell@...com,
	iommu@...ts.linux-foundation.org,
	"Li, Zhen-Hua" <zhen-hual@...com>, doug.hatch@...com,
	ishii.hironobu@...fujitsu.com, bhelgaas@...gle.com,
	billsumnerlinux@...il.com, li.zhang6@...com, dyoung@...hat.com,
	vgoyal@...hat.com
Subject: Re: [PATCH v11 0/10] iommu/vt-d: Fix intel vt-d faults in kdump
 kernel

On Mon, Jun 08, 2015 at 04:50:24PM +0100, David Woodhouse wrote:
> On Mon, 2015-06-08 at 17:29 +0200, Joerg Roedel wrote:
> > Hmm, I also limited this functionality to kdump kernels. Do we still
> > need to preserve these extended data structures even when there is no
> > upstream support for them yet?
> 
> We *do* have upstream support. The 4.1 kernel will use the extended
> root/context tables and will set the DMA_RTADDR_RTT bit in the Root
> Table Address register, even though it doesn't yet actually *use* any
> of the shiny new bits in the extended context tables.
> 
> So the code which copies the context tables needs to take that into
> account.

Right, I missed that until now. So what the code with my changes does
is, it sets the DMA_RTADDR_RTT bit as it would do on a normal boot. But
unlike the root entry table address, this bit can not be changed while
translation is active.

So I think we need to read out that bit when we find translation enabled
and if it is different from what we would set it to, we bail out of any
copying, disable translation and proceed as in a normal boot.

> Yeah. We need the same thing with hardware passthrough — currently I
> think we refuse to put RMRR-afflicted devices into the passthrough
> domain purely because we lack the capability to install the RMRR
> regions if/when we later take it *out* of the hardware passthrough
> domain. Although I can't quite remember the logic there; surely if it's
> RMRR-afflicted and we have iommu=pt, it'll *never* be taken out of the
> 1:1 domain? A device driver might come along and tell us it really is
> 64-bit capable and thus we might put it *in* to the passthrough domain
> where previously we'd kept it out... but taking it *out*... ?

Well, yeah, the logic is complicated. My hope is to move all that logic
to the iommu core code to have it unified between iommu drivers.

The way it should work then is basically: Every device (better:
iommu-group) has a default domain (which can be a PT domain) and if the
device has RMRR mappings, it can not be taken out of that domain. The
default-domain branch of my tree contains the beginnings of that, but
there is still a lot of work to do to get there.


	Joerg

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/