linux-kernel - Re: [RFC] Kernel version numbering scheme change

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: <20081017064751.GE22554@cs181140183.pp.htv.fi>
Date:	Fri, 17 Oct 2008 09:47:51 +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 Thu, Oct 16, 2008 at 08:47:17PM -0700, Greg KH wrote:
> On Thu, Oct 16, 2008 at 07:46:02PM +0300, Adrian Bunk wrote:
> > On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote:
> > > On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
> > >...
> > > > 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...
> > > 
> > > Distros properly patch things and backport "urgent OpenSSL security
> > > updates" to older versions of packages, so they would not run into this
> > > problem.
> > 
> > You didn't get my point.
> > 
> > Let me make an example:
> > 
> > The current Debian release will be supported until one year after the
> > next release gets released.
> > 
> > Someone from the Debian security team send a fixed package to the
> > buildds.
> > 
> > The buildds build packages in chroots.
> > 
> > A buildd may run any Debian release.
> > 
> > And it's perfectly normal that a buildd runs a more recent release of 
> > Debian than the one a package gets built for in a chroot.
> 
> So you are saying the Debian build system would build a package for an
> older release, on a system that is newer,

Packages are built in a chroot with the correct release installed.

> and that build would be
> determining things based on the system it is built on, not what it is
> being built for?

No.

In the example I gave it is OpenSSL that parses the version number of 
the kernel.

> If so, then something is very broken already in the Debian build system
> and I think you have much bigger problems to worry about right now.
> 
> For all other "sane" build systems that I know of, you build against the
> libraries/kernel/gcc/glibc/etc that you are wanting to support it for,
> not against some random-whatever-happened-to-be-installed-on-the-box.

Building in a chroot is hardly "very broken".

And it does build against the correct
libraries/kernel headers/gcc/glibc/etc .

Did you ever use a chroot?


And this was just one example.

What does userspace with the kernel version returned by GDTIOCTL_OSVERS?
I don't know whether it just displays the number, or whether it 
determines anything based on it.

Or what else might parse the version number?

What if some proprietary userspace software like Skype or Flash or 
whatever parses the kernel version number at runtime and barfs on 
2009.2.3 in a way similar to the OpenSSL build system?

WHAT YOU SUGGEST WILL BREAK EXISTING USERSPACE SOFTWARE.

Please admit this fact.


>...
> Hope this helps,
> 
> 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/