linux-kernel - Re: X86: kexec issues with i915 in 3.14

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, 14 Apr 2014 00:28:13 +0000
From:	"Woodhouse, David" <david.woodhouse@...el.com>
To:	"stefani@...bold.net" <stefani@...bold.net>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jiang.liu@...ux.intel.com" <jiang.liu@...ux.intel.com>,
	"daniel.vetter@...ll.ch" <daniel.vetter@...ll.ch>,
	"Zanoni, Paulo R" <paulo.r.zanoni@...el.com>,
	"greg@...ah.com" <greg@...ah.com>
Subject: Re: X86: kexec issues with i915 in 3.14

On Sun, 2014-04-13 at 22:01 +0200, Stefani Seibold wrote:
> Rebooting my kernel vanilla kernel 3.14 will fail with tons of kernel
> log messages:
> 
> [    0.262754] IOMMU: Setting identity map for device 0000:00:1a.0 [0x7c45f000 - 0x7c46bfff]
> [    0.262780] IOMMU: Setting identity map for device 0000:00:14.0 [0x7c45f000 - 0x7c46bfff]
> [    0.262798] IOMMU: Prepare 0-16MiB unity mapping for LPC
> [    0.262807] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
> [    0.262948] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
> [    0.262948] dmar: DRHD: handling fault status reg 3
> [    0.262951] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr ffffe000 
> DMAR:[fault reason 05] PTE Write access is not set

I'm inferring from the subject line that you mean kexec, not
"rebooting"?

It looks like a peripheral device is being left active and doing DMA by
the previous kernel, rather than being shut down. So as soon as the new
kernel resets the IOMMU mappings, that peripheral device is causing
faults.

We really ought to rate-limit the faults and isolate the offending
device before there are 21,000 of them. As discussed elsewhere recently,
we could do with a way to tell the PCI layer that it offended us but I
suppose we could at *least* stop the IOMMU from reporting faults for it.

Is this new behaviour? I'm not sure why this should have changed...

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

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