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: <20081018090117.GR24654@1wt.eu>
Date:	Sat, 18 Oct 2008 11:01:18 +0200
From:	Willy Tarreau <w@....eu>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	Greg KH <greg@...ah.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Kernel version numbering scheme change

On Fri, Oct 17, 2008 at 11:56:04AM +0300, Adrian Bunk wrote:
> On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
> > On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
> >...
> > > Packages are built in a chroot with the correct release installed.
> > 
> > Then why would this break if they are being built against the correct,
> > older, kernel?
> 
> How could you build userspace "against a kernel"?
> 
> sys_*uname() returns the version of the running kernel.

Which is why you don't want your build scripts to rely on that, but
on the target kernel version instead. It's quite common in distros
to patch makefiles and build scripts to force some constants instead
of calls to nasty or misplaced commands. Uname certainly is one of
them.

> > But not against the proper kernel it will be run on, which sounds
> > broken.
> 
> Building software in a chroot is a common thing if you don't want to 
> setup a dedicated machine for a build environment (and all these hyped 
> virtualization solutions tend to not support architectures like alpha
> or parisc).

The chroot is OK when you want to maintain a few packages once in
a while (eg: have it on your notebook to build packages for your
customers' various distros). But it's not suited to maintain full
distros, nor to cross-compile.

> The OpenSSL 0.9.8 config script is existing userspace, and it will 
> break.

And ? All distros shipping version 0.9.8 with a current kernel will
have no problem because they backport fixes only. Once the new kernel
is out, openssl will release a minor update with a few fixes and features,
one of them being tagged as "support for Linux 2.8 and above". New distros
will then have no trouble shipping a standard openssl with a standard
kernel. All software have always worked like this, I really don't see
the problem Adrian.

> That is one example that "Will" definitely break (no matter how broken 
> or how easy to fix it is).

What makes you think that current 0.9.8g will work on 2.6.521 ? One day
you might have to upgrade your openssl anyway. What is important is that
the upgrade follows a smooth path. Adding a two-liner patch in a minor
release to support new versions is smooth.

> > And hey, if it's a problem, just fix userspace reporting to always say
> > we are the 2.6.30 release and go on our merry way, perhaps providing
> > another sysctl if it's really needed (glibc probably wants it, so it
> > would be easy to add.)
> > 
> > That's just a minor technical thing that can be trivially fixed _IF_ we
> > decide it is something that we want to do.
> 
> If we do not continue to report the correct version in sys_*uname()
> (and therefore in "uname -r") we break standard POSIX behavior.

I would not like it if uname -r would not report real version. I'd
better get a tool to force the version if this is needed (ala cpuid).
It reminds me that I had this for years under DOS :-)

Regards,
Willy

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