linux-kernel - Re: kdump failed because of hotplug memory adding in kdump kernel

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] [day] [month] [year] [list]

Date:	Fri, 10 Jan 2014 08:56:17 -0700
From:	Toshi Kani <toshi.kani@...com>
To:	Baoquan <bhe@...hat.com>
Cc:	Vivek Goyal <vgoyal@...hat.com>, kexec@...ts.infradead.org,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	linux-kernel@...r.kernel.org, tangchen@...fujitsu.com,
	linux-acpi@...r.kernel.org, zhangyanfei@...fujitsu.com,
	dyoung@...hat.com
Subject: Re: kdump failed because of hotplug memory adding in kdump kernel

On Fri, 2014-01-10 at 15:11 +0800, Baoquan wrote:
> On 01/09/14 at 02:56pm, Toshi Kani wrote:
 :
> > I am more curious to know how makedumpfile decides what memory ranges to
> > dump.  The 1st kernel may have performed memory hot-add / delete
> > operations before a crash, so it needs to know the valid physical
> > address range at the time of crash, and may not rely on the E820 map
> > from BIOS (which is stale).  Am I right to assume that makedumpfile gets
> > it from the page tables of the 1st kernel?
> 
> makedumpfile just do the dump, what memory ranges to dump is decided in
> 1st kernel by kexec-tools. In 1st kernel, if kexec-tools executed, it
> will find all System Ram memorys which exclude the reserved regions for
> kdump kernel, then build a logical elf file, each load segment is one of
> these System Ram memory regions, its addr and length is written into the
> program header.
> 
> Then makedumpfile just read this elf file, and read all of them and
> dump.
> 
> If after kexec-tools execution and before crash, a hotplug memory is
> removed, udev will check this and trigger a kdump restart, kexec-tools
> is executed again, System Ram region information are stored. The logical
> file header will be passed to 2nd kernel.

Oh, that's how it works.  Thanks for the explanation!  In case of
hot-delete, ideally, the elf file should be updated after a memory
region is put into off-line, but before it is ejected.  But it is
difficult/vulnerable to coordinate such sequence with user space.  So,
the current scheme sounds good to me.

Thanks,
-Toshi

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