linux-kernel - Re: Determine version of kernel that produced vmcore

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: <20070723155803.GA30193@in.ibm.com>
Date:	Mon, 23 Jul 2007 21:28:03 +0530
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	Dan Aloni <da-x@...atomic.org>
Cc:	"Ken'ichi Ohmichi" <oomichi@....nes.nec.co.jp>,
	Don Zickus <dzickus@...hat.com>,
	Neil Horman <nhorman@...hat.com>,
	Bernhard Walle <bwalle@...e.de>, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: Determine version of kernel that produced vmcore

On Mon, Jul 23, 2007 at 04:02:39PM +0300, Dan Aloni wrote:
> On Mon, Jul 23, 2007 at 08:47:23PM +0900, Ken'ichi Ohmichi wrote:
> > 
> > Hi,
> > 
> > 2007/07/23 10:31:47 +0530, Vivek Goyal <vgoyal@...ibm.com> wrote:
> [..]
> > >
> > >I am also in favour of a complete kernel based solution. Export required
> > >info from kernel and let kexec-tools parse that info, pass it to second
> > >kernel and it will be appended to vmcore.
> > >
> > >This will put some restrictions on that we can't keep on changing the
> > >format of the info very frequently and some new features might not work
> > >with older kernels. But I guess, kexec-tools can provide an override option
> > >where dump filtering info can be passed on kexec-tools command line (as
> > >suggested by ken'chi). If user passes this info on command line then
> > >kexec-tools will not read the info exported from kernel. This way new
> > >features can be made to work on older kernels. 
> > 
> > That sounds good.
> 
> Note that currently kexec doesn't actually pass the ELF notes themselves
> to the kernel, but only their physical addresses as extracted from /sys. 
> If we want to be able to pass the notes themselves from userspace, a 
> little more trickery will be needed here.
> 

That should be easy. Like so many other segments kexec prepares, one
more segment need to be created and required elf note data needs to be
put in this segment. 

Right now we create a PT_NOTE type ELF header for every cpu. Now we need
to create few more notes to pass on the OS release, config variables and
debug data to second kernel.

Should we create a separate note for passing on kernel config info something
like "linuxconfig" and every note will contain CONFIG_VARIABLE=VALUE string?

Probably something similar can be done for appropriate debugging data 
instead of putting all the info in one ELF note. Breaking the required
info into multiple generic notes will help it to be used in other things
also down the line. Just a thought....

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