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, 08 Jun 2015 16:50:24 +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 17:29 +0200, Joerg Roedel wrote:
> On Mon, Jun 08, 2015 at 03:26:23PM +0100, David Woodhouse wrote:
> > There are some interesting corner cases to handle here.
> > 
> > Firstly, you don't seem to handle the case of extended root/context
> > tables (where ecap_ecs is set). You need to preserve the DMA_RTADDR_RT
> > bit in the Root Table Address register, surely?
> > 
> > I think we also need to cope with inheriting page tables from a kernel
> > that *doesn't* use extended page tables, even on hardware that supports
> > it. Which means the use of extended page tables in the new kernel would
> > need to be contingent on something *other* than the pure hardware
> > capabilities.
> 
> 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.

> That is still a problem, but not specific to this patch-set. RMRRs will
> not be restored, because domains allocated out of the DMA-API path will
> not get any RMRR mappings. This is also a problem with device hotplug
> (unplug a device with RMRRs and replug it in and the RMRR mappings will
>  be gone).
> 
> I agree that this needs to be fixed.

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*... ?

-- 
dwmw2

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