linux-kernel - Re: [patch] crashdump: fix undefined reference to `elfcorehdr

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, 28 Jul 2008 12:12:41 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Muli Ben-Yehuda <muli@...ibm.com>,
	Simon Horman <horms@...ge.net.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chandru <chandru@...ibm.com>, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Terry Loftin <terry.loftin@...com>,
	Tony Luck <tony.luck@...el.com>, linux-ia64@...r.kernel.org
Subject: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr'

Vivek Goyal <vgoyal@...hat.com> writes:

> On Mon, Jul 28, 2008 at 09:24:46AM +0300, Muli Ben-Yehuda wrote:
>> 
>> With an isolation-capable IOMMU (such as Calgary, VT-d and AMD's
>> IOMMU) on the I/O path, as long as we want to keep DMAs running and
>> going through to memory, we need to keep the IOMMU running, with the
>> same set of permissions and translation tables. If we don't mind DMAs
>> failing, we need to gracefully handle IOMMU DMA faults (where
>> possible---Calgary can't do it at the moment). What we do instead with
>> Calgary (c.f., the patch that instigated this discussion) is a hack,
>> we "reinitialize" the IOMMU with the old IOMMU's translation tables so
>> that DMAs continue working. 
>> 
>
> Hi Muli,
>
> Agree, using old kernel's TCE tables is a hack. As Eric pointed out,
> is there a reason why swiotlb will not work here? (I guess using
> swiotlb will mean disabling iommu and that will again fault if 
> DMA is going on).
>
> So one of the solutions, as eric suggested,  will be to reserve some
> entries in first kernel and then pass that info to second kernel and
> let second kernel use thos entries for setting up DMA and let the
> DMA's of first kernel run untouched.
>
> This patch is effectively doing that (using previous kernel's TCE table),
> except the fact that there are no gurantees that there are free table
> entries when kdump kernel wants to perform a DMA of its own. Should
> probably work though in most of the cases. 
>
>> My preference would be to have stopped all DMAs in the old kernel,
>> which would've made this nastiness go away. Can you explain in simple
>> words why we can't or won't do that?
>
> Is there a reliable way of stopping all ongoing DMAs after kernel crash?

When I investigated this there was no reliable way to stop DMAs from devices,
in a generic way, and a callback to each device in the system in the kexec
on panic path is less reliable then simply avoiding running out of regions
where those DMAs are running.

So it would be quite reasonable to drop all in flight DMA at the iommu.

We do need a way to allow the drivers in the kernel running after the
panic to use DMA.  Which is where the idea of reserving a region of
the iommu comes from.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/