| 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
| ||
|
Date: Tue, 10 Jul 2007 08:02:43 -0400 From: Neil Horman <nhorman@...hat.com> To: "Ken'ichi Ohmichi" <oomichi@....nes.nec.co.jp> Cc: Bernhard Walle <bwalle@...e.de>, Neil Horman <nhorman@...hat.com>, kexec@...ts.infradead.org, linux-kernel@...r.kernel.org Subject: Re: Determine version of kernel that produced vmcore On Tue, Jul 10, 2007 at 12:13:15PM +0900, Ken'ichi Ohmichi wrote: > > Hi, > > On Fri, 6 Jul 2007 17:58:04 +0300, Dan Aloni <da-x@...atomic.org> wrote: > > On Fri, Jul 06, 2007 at 03:28:14PM +0200, Bernhard Walle wrote: > > > Hello, > > > > > > does anybody know a _reliable_ way to determine the version the kernel > > > that produced a vmcore file? This means not scanning for a specific > > > string or something like that which can fail on random memory. > > > > > > Would it make sense to add a ELF PT_NOTE section in the vmcore? > > > > > > Thanks for input! > > (CONFIGFILE means makedumpfile's config file.) > > makedumpfile checks kernel version by reading system_utsname.release > from /proc/vmcore, as you know. If the release and OSRELEASE in CONFIGFILE > don't match, makedumpfile fails. > > Besides Dan's plan, I'm planning the change of CONFIGFILE for distributors. > In the kernel building process, distributors need to make CONFIGFILE > on an older kernel (ex. RHEL5 kernel is built on RHEL4), and OSRELEASE > may be an older kernel. So OSRELEASE should be modified to the building > kernel version by hand, but it is not smart. > > To solve this problem, I'm proposing 2 plans. > Could you give me your opinion ? > > Plan 1: > A new option [--osrelease="string"] is added. > The OSRELEASE of CONFIGFILE is overwritten by "string". > In the kernel building process, distributors should specify "string" > as the building kernel version. > > Plan2: > Remove the OSRELEASE from CONFIGFILE. > Instead of checking the OSRELEASE, makedumpfile only checks whether the > area of /proc/vmcore specified by the symbol "system_utsname" in CONFIGFILE > is the string "2.6.". If CONFIGFILE and /proc/vmcore don't match, the > "system_utsname" must not point to the correct area in most cases. > Old makedumpfile needs OSRELEASE, and it cannot work by new CONFIGFILE. > But I think there are not any problems because old makedumpfile will not > read new CONFIGFILE. Now, CONFIGFILE is used only by RHEL5's kdump initramfs, > the CONFIGFILE is generated during 1st-kernel running. Even if CONFIGFILE > will be updated, makedumpfile can read the CONFIGFILE because makedumpfile > should be updated with CONFIGFILE. > > > I'd like to change the name of CONFIGFILE to mkdfinfo. > Why not, instead of either plan above, just redefine OSRELEASE to be the version of the kernel the config file was built against? i.e. when you build a config file, you need to specify a kernel to extract symbol information from, why not grab the utsname from that kernel and use that to set OSRELEASE? When you're building a config file the running kernel on the system isn't really relevent anyway. Thanks & Regards Neil > > Thanks > Ken'ichi Ohmichi -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@...hat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ - 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