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: <1433773583.2952.52.camel@infradead.org>
Date:	Mon, 08 Jun 2015 15:26:23 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	"Li, Zhen-Hua" <zhen-hual@...com>
Cc:	indou.takao@...fujitsu.com, bhe@...hat.com, joro@...tes.org,
	vgoyal@...hat.com, dyoung@...hat.com,
	iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, kexec@...ts.infradead.org,
	alex.williamson@...hat.com, ddutile@...hat.com,
	ishii.hironobu@...fujitsu.com, bhelgaas@...gle.com,
	doug.hatch@...com, jerry.hoemann@...com, tom.vaden@...com,
	li.zhang6@...com, lisa.mitchell@...com, billsumnerlinux@...il.com,
	rwright@...com
Subject: Re: [PATCH v11 0/10] iommu/vt-d: Fix intel vt-d faults in kdump
 kernel

On Mon, 2015-05-11 at 17:52 +0800, Li, Zhen-Hua wrote:
> To fix this problem, we modifies the behaviors of the intel vt-d in the 
> crashdump kernel:
> 
> For DMA Remapping:
> 1. To accept the vt-d hardware in an active state,
> 2. Do not disable and re-enable the translation, keep it enabled.
> 3. Use the old root entry table, do not rewrite the RTA register.
> 4. Malloc and use new context entry table, copy data from the old ones that
>    used by the old kernel.

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.

> 5. Keep using the old page tables before driver is loaded.
> 6. After device driver is loaded, when it issues the first dma_map command, 
>    free the dmar_domain structure for this device, and generate a new one, so 
>    that the device can be assigned a new and empty page table. 

What if there were RMRRs for this device? Don't we need to ensure that
those are present in the "new and empty page table" when we take it
over?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

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