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-next>] [day] [month] [year] [list]
Date:	Mon, 11 Dec 2006 15:11:08 +0000
From:	Andy Whitcroft <apw@...dowen.org>
To:	Herbert Poetzl <herbert@...hfloor.at>, Andi Kleen <ak@...e.de>
CC:	Andrew Morton <akpm@...l.org>, Linus Torvalds <torvalds@...l.org>,
	linux-kernel@...r.kernel.org, Steve Fox <drfickle@...ibm.com>
Subject: 2.6.19-git13: uts banner changes break SLES9 (at least)

test.kernel.org testing seems to have shaken out a problem with the 
kernel banner changing, introduced by this commit:

	[PATCH] Fix linux banner utsname information
	commit a2ee8649ba6d71416712e798276bf7c40b64e6e5

We first noticed it with 2.6.19-git13 as we use this version string as 
part of our boot validation process, which started tripping for every 
job.  Although we have been able to modify our validation, I am 
concerned that this is a widespread mechanism for finding the version of 
the kernel from non-running kernels.  It appears that SLES9 and possibly 
SLES10 is going to be affected too.

On a SLES9 box here, making an initrd for this kernel fails as below:

	Module list:	sym53c8xx reiserfs
	Kernel version:	%s (powerpc)
	Kernel image:	/boot/vmlinuz-autobench
	Initrd image:	/boot/initrd-autobench.img.new
	No modules found for kernel %s

If you follow the initrd build process it appears that they look at the 
compressed kernel and extract the internal version number from it, in 
order to find the modules.  For this they use the get_kernel_version, 
which starts returning %s with this change:

	# get_kernel_version /boot/vmlinuz-autobench
	%s

Obviously this method is dubious at best for finding the kernel version 
here.  I do wonder if there should be some approved interface for 
getting this information out of the kernel.  Perhaps something similar 
to the IKCFG_ST<config>IKCFG_ED bracketing the uname structure or something.

Andi, just a heads up.

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