linux-kernel - Re: [PATCH 0/8] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO

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: <1398854973.12733.23.camel@i7.infradead.org>
Date:	Wed, 30 Apr 2014 11:49:33 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Bill Sumner <bill.sumner@...com>,
	"Hoemann, Jerry" <jerry.hoemann@...com>
Cc:	indou.takao@...fujitsu.com, bhe@...hat.com, joro@...tes.org,
	linux-pci@...r.kernel.org, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org,
	doug.hatch@...com, ishii.hironobu@...fujitsu.com,
	bhelgaas@...gle.com, zhenhua@...com
Subject: Re: [PATCH 0/8] iommu/vt-d: Fix crash dump failure caused by legacy
 DMA/IO

On Thu, 2014-04-24 at 18:36 -0600, Bill Sumner wrote:
> 
> This patch set modifies the behavior of the Intel iommu in the crashdump kernel: 
> 1. to accept the iommu hardware in an active state,
> 2. to leave the current translations in-place so that legacy DMA will continue
>    using its current buffers until the device drivers in the crashdump kernel
>    initialize and initialize their devices,
> 3. to use different portions of the iova address ranges for the device drivers
>    in the crashdump kernel than the iova ranges that were in-use at the time
>    of the panic.  

There could be all kinds of existing mappings in the DMA page tables,
and I'm not sure it's safe to preserve them. What prevents the crashdump
kernel from trying to use any of the physical pages which are
accessible, and which could thus be corrupted by stray DMA?

In fact, the old kernel could even have set up 1:1 passthrough mappings
for some devices, which would then be able to DMA *anywhere*. Surely we
need to prevent that?

After the last round of this patchset, we discussed a potential
improvement where you point every virtual bus address at the *same*
physical scratch page.

That way, we allow the "rogue" DMA to continue to the same virtual bus
addresses, but it can only ever affect one piece of physical memory and
can't have detrimental effects elsewhere.

Was that option considered and discounted for some reason? It seems like
it would make sense...

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

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