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

On Thu, Jul 19, 2007 at 12:39:15PM -0400, Don Zickus wrote:
[..]
> 
> I am not a big fan of this approach as it forces distros to require
> kexec-tools when building a kernel.  Even Joe Hacker who wants a custom
> kernel (and not interested in kexec) would have to not only download the
> kernel.src.rpm but kexec-tools just to build a kernel that probably
> doesn't have kexec enabled.
> 
> I had to deal with a similar experience when providing a build dependency
> on the unifdef package when create the kernel-headers rpm for RHEL-5.  A
> lot of people were confused and upset by this dependency.  Luckily
> upstream resolved this by just putting similar code in the kernel/scripts
> directory and thus removing the dependency (well not for RHEL-5).  I would
> rather not have to deal with this again unless I know there is a more
> permanent solution that would remove this dependency.
> 

That's a good point Don. kernel rpm being dependent on kexec-tools rpm is
not a good idea.

> After talking to Dave Anderson about this more, I start to understand why
> Ken'ichi prefers to implement the new features in userspace instead of the
> kernel (it makes things automatically work with older kernels), but I
> still am not a big fan of it.  I was hoping for a complete in kernel
> solution (that way you never need the vmlinux file).  Perhaps makedumpfile
> can support both vmlinux files (if provided) or interface with the kernel
> (if the vmlinux is not provided?).
> 

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. 

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/