linux-kernel - Re: Kernel version numbers after 4.9.255 and 4.4.255

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: <20210205191105.128c6e48@coco.lan>
Date:   Fri, 5 Feb 2021 19:11:05 +0100
From:   Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To:     Tony Battersby <tonyb@...ernetics.com>
Cc:     Jiri Slaby <jirislaby@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org,
        Jari Ruusu <jariruusu@...tonmail.com>,
        David Laight <David.Laight@...LAB.COM>,
        Christoph Biedl <linux-kernel.bfrz@...chmal.in-ulm.de>,
        linux-media@...r.kernel.org
Subject: Re: Kernel version numbers after 4.9.255 and 4.4.255

Em Fri, 5 Feb 2021 12:31:05 -0500
Tony Battersby <tonyb@...ernetics.com> escreveu:

> On 2/4/21 6:00 AM, Jiri Slaby wrote:
> > Agreed. But currently, sublevel won't "wrap", it will "overflow" to 
> > patchlevel. And that might be a problem. So we might need to update the 
> > header generation using e.g. "sublevel & 0xff" (wrap around) or 
> > "sublevel > 255 : 255 : sublevel" (be monotonic and get stuck at 255).
> >
> > In both LINUX_VERSION_CODE generation and KERNEL_VERSION proper.  
> 
> My preference would be to be monotonic and get stuck at 255 to avoid
> breaking out-of-tree modules.  If needed, add another macro that
> increases the number of bits that can be used to check for sublevels >
> 255, while keeping the old macros for compatibility reasons.  Since
> sublevels > 255 have never existed before, any such checks must be
> newly-added, so they can be required to use the new macros.
> 
> I do not run the 4.4/4.9 kernels usually, but I do sometimes test a wide
> range of kernels from 3.18 (gasp!) up to the latest when bisecting,
> benchmarking, or debugging problems.  And I use a number of out-of-tree
> modules that rely on the KERNEL_VERSION to make everything work.  Some
> out-of-tree modules like an updated igb network driver might be needed
> to make it possible to test the old kernel on particular hardware.
> 
> In the worst case, I can patch LINUX_VERSION_CODE and KERNEL_VERSION
> locally to make out-of-tree modules work.  Or else just not test kernels
> with sublevel > 255.

Overflowing LINUX_VERSION_CODE breaks media applications. Several media
APIs have an ioctl that returns the Kernel version:

	drivers/media/cec/core/cec-api.c:       caps.version = LINUX_VERSION_CODE;
	drivers/media/mc/mc-device.c:   info->media_version = LINUX_VERSION_CODE;
	drivers/media/v4l2-core/v4l2-ioctl.c:   cap->version = LINUX_VERSION_CODE;
	drivers/media/v4l2-core/v4l2-subdev.c:          cap->version = LINUX_VERSION_CODE;

Those can be used by applications in order to enable some features that
are available only after certain Kernel versions.

This is somewhat deprecated, in favor of the usage of some other
capability fields, but for instance, the v4l2-compliance userspace tool
have two such checks:

	utils/v4l2-compliance/v4l2-compliance.cpp
	640:	fail_on_test((vcap.version >> 16) < 3);
	641:	if (vcap.version >= 0x050900)  // Present from 5.9.0 onwards

As far as I remember, all such checks are against major.minor. So,
something like:

	sublevel = (sublevel > 0xff) ? 0xff : sublevel;

inside KERNEL_VERSION macro should fix such regression at -stable.

Thanks,
Mauro