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]

Message-ID: <1433854550.19447.15.camel@infradead.org>
Date:	Tue, 09 Jun 2015 13:55:50 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Joerg Roedel <joro@...tes.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, 2015-06-08 at 18:13 +0200, Joerg Roedel wrote:
> 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.

Given that this is only for kdump and not the general case of kexec,
that's probably tolerable. Of course we do still need to make it *not*
broken for the case where DMA_RTADDR_RTT is set, as it is at the
moment.

And I suspect if we're doing that, it might be simple enough to make it
convert to/from the extended page tables. I don't think we want to
preserve PASID tables; only the "second level" (i.e. traditional)
translation. So we could happily pull the page table pointer out of
either kind of context entry, and install it into either kind. I think
there's a simple mapping of translation types too. I need to sort out
the translation types when adding the real PASID support (imminently!)
anyway.

-- 
dwmw2

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