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 09:24:46 +0300
From:	Muli Ben-Yehuda <muli@...ibm.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	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, Vivek Goyal <vgoyal@...hat.com>,
	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'

On Sun, Jul 27, 2008 at 10:39:30PM -0700, Eric W. Biederman wrote:
> Simon Horman <horms@...ge.net.au> writes:
> 
> > There has long been a strong aversion to providing the second
> > kernel with flags like im_in_kexec or im_in_kdump, as its felt
> > that this kind of problem is better handled by making sure that
> > the hardware is in a sensible state before leaving the
> > first-kernel.  But this is arguably more reasonable in the kexec
> > case than the kdump case.
> 
> That and because we can generally solve the specific problem with a
> general feature.  Something we can enable/disable on the command
> line if needed.  Right now this is especially interesting as on
> several architectures distros are not building special kdump kernels
> but have a single kernel binary that works in both cases.
> 
> Skimming through your patches this is a case we really do need to
> implement and handle cleanly.
> 
> Currently we leave DMA running in the kexec on panic case.  We avoid
> problems by only running out of a reserved area of memory.
> 
> As as general strategy that is fine.  However we have not
> implemented that strategy in the case of IOMMUs.  And we are having
> trouble with IOMMUs.
> 
> My hunch is that we should implement options to reserve a section of
> the iommu and to tell to the iommu to use the previously reserved
> section. Although turning iommus off altogether and simply using
> swiotlb may be acceptable.  In which case we should just force usage
> of the swiotlb on the command line in /sbin/kexec.

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. 

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?

Cheers,
Muli
--
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/