linux-kernel - Re: [PATCH v8 02/10] iommu/vt-d: Items required for kdump

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: <20150112164803.GG6343@8bytes.org>
Date:	Mon, 12 Jan 2015 17:48:03 +0100
From:	Joerg Roedel <joro@...tes.org>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	"Li, Zhen-Hua" <zhen-hual@...com>, dwmw2@...radead.org,
	indou.takao@...fujitsu.com, bhe@...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 v8 02/10] iommu/vt-d: Items required for kdump

On Mon, Jan 12, 2015 at 11:15:38AM -0500, Vivek Goyal wrote:
> On Mon, Jan 12, 2015 at 05:06:46PM +0100, Joerg Roedel wrote:
> > On Mon, Jan 12, 2015 at 10:29:19AM -0500, Vivek Goyal wrote:
> > > Kdump has the notion of backup region. Where certain parts of old kernels
> > > memory can be moved to a different location (first 640K on x86 as of now)
> > > and new kernel can make use of this memory now.
> > > 
> > > So we will have to just make sure that no parts of this old page table
> > > fall into backup region.
> > 
> > Uuh, looks like the 'iommu-with-kdump-issue' isn't complicated enough
> > yet ;)
> > Sadly, your above statement is true for all hardware-accessible data
> > structures in IOMMU code. I think about how we can solve this, is there
> > an easy way to allocate memory that is not in any backup region?
> 
> Hmm..., there does not seem to be any easy way to do this. In fact, as of
> now, kernel does not even know where is backup region. All these details are
> managed by user space completely (except for new kexec_file_load() syscall).
> 
> That means we are left with ugly options now.
> 
> - Define per arch kexec backup regions in kernel and export it to user
>   space and let kexec-tools make use of that deinition (instead of
>   defining its own). That way memory allocation code in kernel can look
>   at this backup area and skip it for certain allocations.

Yes, that makes sense. In fact, I think all allocations for DMA memory
need to take this into account to avoid potentially serious data
corruption.
If any memory for a disk superblock gets allocated in backup memory and
a kdump happens, the new kernel might zero out that area and the disk
controler then writes the zeroes to disk instead of the superblock.


	Joerg

--
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/