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: <20070709114131.GA18750@localdomain>
Date:	Mon, 9 Jul 2007 14:41:31 +0300
From:	Dan Aloni <da-x@...atomic.org>
To:	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: Determine version of kernel that produced vmcore

On Mon, Jul 09, 2007 at 11:21:54AM +0200, Bernhard Walle wrote:
> Hello,
> 
> * Dan Aloni <da-x@...atomic.org> [2007-07-06 16:58]:
> > 
> > Redhat has a makedumpinfo util which they intend to use as slim
> > kernel-version-independent utility on kdump rootfs in order to
> > save /proc/vmcore in a compact manner.
> 
> I think you mean makedumpfile, don't you?

Yes, a typo, sorry.

> > A patch that I am working on will make it possible to integrate
> > the output of 'makedumpinfo -g' into vmlinux as the final build
> > stage of the kernel. This information will be presented itself
> > as /proc/kcore.info for the first kernel throughout its entire
> > execution.
> 
> That sounds good. But I doubt that kernel developers like the idea of
> needing another utility in the build process ...

I don't think it would add much complexity to build process as it 
is now, just like the other tools that transparently do post-linking 
modifications. As far as the developer is concerned, there's just
the vmlinux and/or bzImage files that get emitted at the end.

> > Then inside initramfs of the first kernel, a small 
> > util will modify the vmlinux file of the kdump kernel before it
> > gets loaded so that another special file appearing as 
> > /proc/vmcore.info under the kdump kernel will present the same
> > info. 
> 
> Where do you get the info from? If you're in the kdump initrd,
> then the kdump kernel is already loaded. Do you want to attach the
> info from the crashed kernel to the initrd of the kdump kernel?

Not exactly. Let me describe the procedure in greater detail.
Basically, it would go like this:

1. <normal bootloader boot>
2. <normal initramfs>
3. embed_configfile /proc/kcore.info /vmlinux-kdump
4. kexec -l vmlinux-kdump <....>
5. <boot continues>
6. <crash>
7. <kdump kernel boot>
8. <kdump initramfs runs>
9. makedumpfile -i /proc/vmcore.info <....>

NOTES:
** in step 3 embed_configfile modifies vmlinux-kdump in place, 
   copying /proc/kcore.info into the data section of the vmlinux-kdump 
   at certain symbol (e.g. 'char core_info[0x1000]').
** in step 9 that data section variable (e.g. core_info) which was 
   originally holds the content of /proc/kcore.info is being presented 
   as /proc/vmcore.info for the util to use.

To complete the picture, at the final build stage of vmlinux we 
would have this:

makedumpfile -g vmlinux.configfile -x vmlinuxx
embed_configfile vmlinux.configfile vmlinux
rm vmlinux.configfile

BTW I think there could be a confusion between makedumpfile's 
CONFIGFILE and the .config file, so we should pick a different 
name for it...

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ