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]
Date:	Thu, 16 Oct 2008 15:49:43 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Greg KH <greg@...ah.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Kernel version numbering scheme change

On Wed, Oct 15, 2008 at 05:25:09PM -0700, Greg KH wrote:
> Hi,

Hi Greg,

>...
> Yes, we can handle the major/minor macros in the kernel to provide a
> compatible number so that automated scripts will not break, that's not a
> big deal.
> 
> Any thoughts?
>...

how much of userspace breaks when we suddenly "just for fun" change the 
version numbering scheme in a very radical way?

I'm not thinking of scripts for building the kernel.

I'm thinking of the fact that starting with glibc different pieces of 
userspace software interpret the kernel version number they get from 
various sources like e.g. <linux/version.h>, "uname -r" or an ioctl.

As a random example, the "config" script of OpenSSL 0.9.8g contains the 
following:

<--  snip  -->

...
RELEASE=`(uname -r) 2>/dev/null` || RELEASE="unknown"
...
case "${SYSTEM}:${RELEASE}:${VERSION}:${MACHINE}" in
...
    Linux:[2-9].*)
        echo "${MACHINE}-whatever-linux2"; exit 0
        ;;

    Linux:1.*)
        echo "${MACHINE}-whatever-linux1"; exit 0
        ;;
...

<--  snip  -->


Change the version number of the kernel in the way you suggest, and 
trying to build it will fail with:

<--  snip  -->

$ ./config
Operating system: x86_64-whatever-Linux
This system (Linux) is not supported. See file INSTALL for details.
$ 

<--  snip  -->


If a distribution will try to autobuild an urgent OpenSSL security 
update for their stable release in a chroot on a machine running
kernel 2009.2.3 they will surely love you for being responsible
for this...


> thanks,
> 
> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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