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: <20070713074927.GA15920@suse.de>
Date:	Fri, 13 Jul 2007 09:49:27 +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

* Vivek Goyal <vgoyal@...ibm.com> [2007-07-13 05:58]:
> Given the fact that more and more architectures are supporting multiple
> page sizes. Now one can also export relevant kernel CONFIG variables
> through this ELF note. makedumpfile's job will be simpler. You don't have
> to make any guesses about various config options like page size.
> 
> This approach will make second kernel truly independent of first kernel.
> Currently, if first kernel changes one shall have to regenerate the 
> initrd for second kenrel. Hence in a sense, second kernel is dependent on
> first kernel. Now kernel will export all the required data for dump filtering
> so one does not have to rebuild the seond kernel initrd even if first kernel
> changes.

That's only the RedHat mechanism. You can copy all CONFIGFILEs to the
initrd, and then pick the right one via the version. Then, you only
have to regenerate the initrd when you *install* a new first kernel,
not when you boot a new first kernel. And that's also why I wanted the
kernel version to be accessible in the crashkernel ...

> I think overall the approach of exporting right info from kernel should 
> help. Only thing is that we shall have to manage the ELF note better in
> terms of making it more generic.

Basically I like the idea of exporting the information from the kernel
without generating the CONFIGFILE. The only big problem I see that the
makedumpfile release cycles would depend on the kernel release cycles,
and, you cannot add new features to makedumpfile for old kernels since
you always rely on the information which is exported.

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/