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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070709204938.GA21663@suse.de>
Date:	Mon, 9 Jul 2007 22:49:38 +0200
From:	Bernhard Walle <bwalle@...e.de>
To:	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: Determine version of kernel that produced vmcore

Hi,

* Dan Aloni <da-x@...atomic.org> [2007-07-09 13:41]:
> > > 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.

I didn't complain about the complexity but about the requirement of an
additional tool. However, I think it will be configurable.

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

I don't see why an additional tool would be needed here. kexec already
modifies symbols, so why not adding the functionality into kexec? The
advantage would be that there's no on-disk modification necessary.

Another issue: Some parameters of makedumpfile (currently the page
size) are read from the running system. If you build the configuration
file while building the kernel, you always have the .config which
contains the page size. So it would be possible to extend the
makedumpfile utility to read that parts from a .config, and that would
remove a dependency that page size of the running kernel matches the
page size of the building kernel. On IA64, that's not always the case.

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

Aggreed. Your suggestion? :)


Thanks,
   Bernhard
-
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/