linux-kernel - Re: [patch 0/9] kdump: Patch series for s390 support

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:	Fri, 15 Jul 2011 16:21:57 +0200
From:	Michael Holzheu <holzheu@...ux.vnet.ibm.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Martin Schwidefsky <schwidefsky@...ibm.com>, ebiederm@...ssion.com,
	hbabu@...ibm.com, mahesh@...ux.vnet.ibm.com,
	oomichi@....nes.nec.co.jp, horms@...ge.net.au,
	heiko.carstens@...ibm.com, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org
Subject: Re: [patch 0/9] kdump: Patch series for s390 support

On Thu, 2011-07-14 at 14:05 -0400, Vivek Goyal wrote:
> On Thu, Jul 14, 2011 at 01:55:32PM -0400, Vivek Goyal wrote:
> 
> [..]
> > > > So we first try to take purgatory path which does the checksum and is
> > > > consistent with other architectures. If that does not work in case
> > > > of hard hang, you always have the option of IPLing the stand alone tool
> > > > later manually.
> > > 
> > > How are we suddenly on the purgatory path again? The code that gets
> > > control in case of a hard crash + IPL is the stand-alone dump tool,
> > > not the purgatory code.
> > 
> > I think that's the biggest contetion point. From the start of discussion
> > you have this hardcoded requirement that the moment panic() happens
> > you are jumping to some IPL code and that's what I am questioning. Why
> > can't you execute some more code after panic() (purgatory), before
> > you jump to IPL code (only if you have to). 
> > 
> 
> In your parlance of shutdown actions, I think it is equivalnet to saying
> that "kdump" is a shutdown action and that that means is that for specific
> trigger points we will execute "crash_kexec()" function which will try
> to capture the dump.
> 
> In user space I think one can modify the kexec-tools infrastrucuture a
> bit so that one is able to define an entry point in case checksum of
> loaded segment failes. Once you are loding kdump kernel, you can define
> that entry point. (And this would be jump to IPL etc.).

You mean to jump back into the crashed kernel code in case the kdump
checksum failed?

In the meantime I was looking a bit more into the kexec code to find
out, what we would have to do, if we use the preallocated ELF header as
you want us to do. With our actual solution, we do not have to reserve
any special areas for the kdump kernel. Now we have to reserve the ELF
header. So what are the options?

The x86 implementation uses a kernel parameter "memmap=exactmap" to do
that.

On ia64 - if I understood the code correctly - they seem to pass a kdump
segment "EFI_memmap" to the kdump kernel that contains information about
all loaded kexec segments. With this segment they can find out the size
of the ELF header segment in the kdump kernel and then do the memory
reservation at boot time. Is that correct?

Michael


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