I'm announcing the release of the 4.9.256 kernel.
This, and the 4.4.256 release are a little bit "different" than normal.
This contains only 1 patch, just the version bump from .255 to .256 which ends
up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently
than normal due to the "overflow".
With this release, KERNEL_VERSION(4, 9, 256) is the same as KERNEL_VERSION(4, 10, 0).
Nothing in the kernel build itself breaks with this change, but given that this
is a userspace visible change, and some crazy tools (like glibc and gcc) have
logic that checks the kernel version for different reasons, I wanted to do this
release as an "empty" release to ensure that everything still works properly.
So, this is a YOU MUST UPGRADE requirement of a release. If you rely on the
4.9.y kernel, please throw this release into your test builds and rebuild the
world and let us know if anything breaks, or if all is well.
Go forth and do full system rebuilds! Yocto and Gentoo are great for this, as
will systems that use buildroot.
I'll try to hold off on doing a "real" 4.9.y release for a 9eek to give
everyone a chance to test this out and get back to me. The pending patches in
the 4.9.y queue are pretty serious, so I am loath to wait longer than that,
consider yourself warned...
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Greg Kroah-Hartman (1):
Linux 4.9.256
diff --git a/Makefile b/Makefile
index 4780b5f80b2a..69af44d3dcd1 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 255
+SUBLEVEL = 256
EXTRAVERSION =
NAME = Roaring Lionus
* Greg Kroah-Hartman:
> I'm announcing the release of the 4.9.256 kernel.
>
> This, and the 4.4.256 release are a little bit "different" than normal.
>
> This contains only 1 patch, just the version bump from .255 to .256 which ends
> up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently
> than normal due to the "overflow".
>
> With this release, KERNEL_VERSION(4, 9, 256) is the same as KERNEL_VERSION(4, 10, 0).
>
> Nothing in the kernel build itself breaks with this change, but given
> that this is a userspace visible change, and some crazy tools (like
> glibc and gcc) have logic that checks the kernel version for different
> reasons, I wanted to do this release as an "empty" release to ensure
> that everything still works properly.
I'm looking at this from a glibc perspective. glibc took the
KERNEL_VERSION definition and embedded the bit layout into the
/etc/ld.so.cache, as part of the file format. Exact impact is still
unclear at this point.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
On Mon, Feb 08, 2021 at 01:57:12PM +0100, Florian Weimer wrote:
> * Greg Kroah-Hartman:
>
> > I'm announcing the release of the 4.9.256 kernel.
> >
> > This, and the 4.4.256 release are a little bit "different" than normal.
> >
> > This contains only 1 patch, just the version bump from .255 to .256 which ends
> > up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently
> > than normal due to the "overflow".
> >
> > With this release, KERNEL_VERSION(4, 9, 256) is the same as KERNEL_VERSION(4, 10, 0).
> >
> > Nothing in the kernel build itself breaks with this change, but given
> > that this is a userspace visible change, and some crazy tools (like
> > glibc and gcc) have logic that checks the kernel version for different
> > reasons, I wanted to do this release as an "empty" release to ensure
> > that everything still works properly.
>
> I'm looking at this from a glibc perspective. glibc took the
> KERNEL_VERSION definition and embedded the bit layout into the
> /etc/ld.so.cache, as part of the file format. Exact impact is still
> unclear at this point.
If we "cap" this at 4, 9, 255 according to what userspace sees, will
that be a problem if we increase the number reported by uname(2)?
And when is the ld.so.cache file "regenerated"?
thanks,
greg k-h
On 05/02/2021 16.26, Greg Kroah-Hartman wrote:
> I'm announcing the release of the 4.9.256 kernel.
>
> This, and the 4.4.256 release are a little bit "different" than normal.
>
> This contains only 1 patch, just the version bump from .255 to .256 which ends
> up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently
> than normal due to the "overflow".
>
> With this release, KERNEL_VERSION(4, 9, 256) is the same as KERNEL_VERSION(4, 10, 0).
I think this is a bad idea. Many kernel features can only be discovered
by checking the kernel version. If a feature was introduced in 4.10,
then an application can be tricked into thinking a 4.9 kernel has it.
IMO, better to stop LINUX_VERSION_CODE at 255 and introduce a
LINUX_VERSION_CODE_IMPROVED that has more bits for patchlevel.
> Nothing in the kernel build itself breaks with this change, but given that this
> is a userspace visible change, and some crazy tools (like glibc and gcc) have
> logic that checks the kernel version for different reasons, I wanted to do this
> release as an "empty" release to ensure that everything still works properly.
Even if glibc and gcc work, other programs may not.
I have two such cases. They don't depend on 4.9, but they're examples of
features that are not discoverable by other means.
> So, this is a YOU MUST UPGRADE requirement of a release. If you rely on the
> 4.9.y kernel, please throw this release into your test builds and rebuild the
> world and let us know if anything breaks, or if all is well.
>
> Go forth and do full system rebuilds! Yocto and Gentoo are great for this, as
> will systems that use buildroot.
>
> I'll try to hold off on doing a "real" 4.9.y release for a 9eek to give
> everyone a chance to test this out and get back to me. The pending patches in
> the 4.9.y queue are pretty serious, so I am loath to wait longer than that,
> consider yourself warned...
>
> The updated 4.9.y git tree can be found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
> and can be browsed at the normal kernel.org git web browser:
> https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
>
> thanks,
>
> greg k-h
>
> ------------
>
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Greg Kroah-Hartman (1):
> Linux 4.9.256
>
>
On Mon, Feb 08, 2021 at 05:50:21PM +0200, Avi Kivity wrote:
> On 05/02/2021 16.26, Greg Kroah-Hartman wrote:
> > I'm announcing the release of the 4.9.256 kernel.
> >
> > This, and the 4.4.256 release are a little bit "different" than normal.
> >
> > This contains only 1 patch, just the version bump from .255 to .256 which ends
> > up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently
> > than normal due to the "overflow".
> >
> > With this release, KERNEL_VERSION(4, 9, 256) is the same as KERNEL_VERSION(4, 10, 0).
>
>
> I think this is a bad idea. Many kernel features can only be discovered by
> checking the kernel version. If a feature was introduced in 4.10, then an
> application can be tricked into thinking a 4.9 kernel has it.
>
>
> IMO, better to stop LINUX_VERSION_CODE at 255 and introduce a
> LINUX_VERSION_CODE_IMPROVED that has more bits for patchlevel.
We are going to stop LINUX_VERSION_CODE at 255 now, see the posted
patches from Sasha, I think we are now ok.
thanks,
greg k-h
On Mon, Feb 08, 2021 at 05:50:21PM +0200, Avi Kivity wrote:
>On 05/02/2021 16.26, Greg Kroah-Hartman wrote:
>>I'm announcing the release of the 4.9.256 kernel.
>>
>>This, and the 4.4.256 release are a little bit "different" than normal.
>>
>>This contains only 1 patch, just the version bump from .255 to .256 which ends
>>up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently
>>than normal due to the "overflow".
>>
>>With this release, KERNEL_VERSION(4, 9, 256) is the same as KERNEL_VERSION(4, 10, 0).
>
>
>I think this is a bad idea. Many kernel features can only be
>discovered by checking the kernel version. If a feature was introduced
>in 4.10, then an application can be tricked into thinking a 4.9 kernel
>has it.
>
>
>IMO, better to stop LINUX_VERSION_CODE at 255 and introduce a
In the upstream (and new -stable fix) we did this part.
>LINUX_VERSION_CODE_IMPROVED that has more bits for patchlevel.
Do you have a usecase where it's actually needed? i.e. userspace that
checks for -stable patchlevels?
--
Thanks,
Sasha
On 2/8/21 8:57 PM, Sasha Levin wrote:
> On Mon, Feb 08, 2021 at 05:50:21PM +0200, Avi Kivity wrote:
>> On 05/02/2021 16.26, Greg Kroah-Hartman wrote:
>>> I'm announcing the release of the 4.9.256 kernel.
>>>
>>> This, and the 4.4.256 release are a little bit "different" than normal.
>>>
>>> This contains only 1 patch, just the version bump from .255 to .256
>>> which ends
>>> up causing the userspace-visable LINUX_VERSION_CODE to behave a bit
>>> differently
>>> than normal due to the "overflow".
>>>
>>> With this release, KERNEL_VERSION(4, 9, 256) is the same as
>>> KERNEL_VERSION(4, 10, 0).
>>
>>
>> I think this is a bad idea. Many kernel features can only be
>> discovered by checking the kernel version. If a feature was
>> introduced in 4.10, then an application can be tricked into thinking
>> a 4.9 kernel has it.
>>
>>
>> IMO, better to stop LINUX_VERSION_CODE at 255 and introduce a
>
> In the upstream (and new -stable fix) we did this part.
>
>> LINUX_VERSION_CODE_IMPROVED that has more bits for patchlevel.
>
> Do you have a usecase where it's actually needed? i.e. userspace that
> checks for -stable patchlevels?
>
Not stable patchlevels, but minors. So a change from 4.9 to 4.10 could
be harmful.
I have two such examples (not on the 4.9->4.10 boundary), but they test
the runtime version from uname(), not LINUX_VERSION_CODE, so they would
be vulnerable to such a change.
* Greg Kroah-Hartman:
> I'm announcing the release of the 4.9.256 kernel.
>
> This, and the 4.4.256 release are a little bit "different" than normal.
>
> This contains only 1 patch, just the version bump from .255 to .256
> which ends up causing the userspace-visable LINUX_VERSION_CODE to
> behave a bit differently than normal due to the "overflow".
>
> With this release, KERNEL_VERSION(4, 9, 256) is the same as KERNEL_VERSION(4, 10, 0).
>
> Nothing in the kernel build itself breaks with this change, but given
> that this is a userspace visible change, and some crazy tools (like
> glibc and gcc) have logic that checks the kernel version for different
> reasons, I wanted to do this release as an "empty" release to ensure
> that everything still works properly.
As promised, I looked at this from the glibc perspective.
A dynamically linked glibc reads the LINUX_VERSION_CODE in the ELF note
in the vDSO.
Statically linked binaries use the uname system call and parse the
release field in struct utsname. If the uname system call fails, there
is also /proc fallback, but I believe that path is unused.
The glibc dynamic linker falls back to uname if the vDSO cannot be
located.
The LINUX_VERSION_CODE format is also used in /etc/ld.so.cache. This is
difficult to change because a newer ldconfig is supposed to build a
cache that is compatible with older glibc versions (two-way
compatibility). The information in /etc/ld.so.cache is copied from the
ELF_NOTE_ABI/NT_GNU_ABI_TAG ELF note in the DSOs; the note format is not
subject to overflows because it uses 32-bit values for the component
versions.
glibc uses the current kernel's LINUX_VERSION_CODE for two purposes: for
its own “kernel too old” check (glibc refuses to start in this case),
and to skip loading DSOs which have an ELF_NOTE_ABI/NT_GNU_ABI_TAG that
indicates a higher kernel version than the current kernel. glibc does
not use LINUX_VERSION_CODE to detect features or activate workarounds
for kernel bugs.
The overflow from 4.9.256 to 4.10.0 means that we might get spurious
passes on these checks. Worst case, it can happen that if the system
has a DSO in two versions on the library search path, one for kernel
4.10 and one for kernel 4.9 or earlier (in that order), we now load the
4.10 version on a 4.9 kernel. Previously, loading the 4.10 DSO failed,
and the fallback version for earlier kernels was used. That would be
real breakage.
Our options in userspace are limited because whatever changes we make to
glibc today are unlikely to reach people running 4.4 or 4.9 kernels
anytime soon, if ever. Clamping the sublevel field of
LINUX_VERSION_CODE in the vDSO to 255 only benefits dynamically linked
binaries, but it could be that this is sufficient to paper over this
issue.
There's also the question whether these glibc checks are valuable at
all. It encourages kernel patching to lie about kernel versions, making
diagnostics harder (e.g., reporting 3.10 if it's really a 2.6.32 with
lots of system call backports). The ELF_NOTE_ABI/NT_GNU_ABI_TAG DSO
selection is known to cause endless problems with Qt, basically the only
large-scale user of this feature. Perhaps we should remove it, but it
would also break the fallback DSO approach mentioned above.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
On Thu, Feb 11, 2021 at 11:48:41AM +0100, Florian Weimer wrote:
> * Greg Kroah-Hartman:
>
> > I'm announcing the release of the 4.9.256 kernel.
> >
> > This, and the 4.4.256 release are a little bit "different" than normal.
> >
> > This contains only 1 patch, just the version bump from .255 to .256
> > which ends up causing the userspace-visable LINUX_VERSION_CODE to
> > behave a bit differently than normal due to the "overflow".
> >
> > With this release, KERNEL_VERSION(4, 9, 256) is the same as KERNEL_VERSION(4, 10, 0).
> >
> > Nothing in the kernel build itself breaks with this change, but given
> > that this is a userspace visible change, and some crazy tools (like
> > glibc and gcc) have logic that checks the kernel version for different
> > reasons, I wanted to do this release as an "empty" release to ensure
> > that everything still works properly.
>
> As promised, I looked at this from the glibc perspective.
>
> A dynamically linked glibc reads the LINUX_VERSION_CODE in the ELF note
> in the vDSO.
>
> Statically linked binaries use the uname system call and parse the
> release field in struct utsname. If the uname system call fails, there
> is also /proc fallback, but I believe that path is unused.
>
> The glibc dynamic linker falls back to uname if the vDSO cannot be
> located.
>
> The LINUX_VERSION_CODE format is also used in /etc/ld.so.cache. This is
> difficult to change because a newer ldconfig is supposed to build a
> cache that is compatible with older glibc versions (two-way
> compatibility). The information in /etc/ld.so.cache is copied from the
> ELF_NOTE_ABI/NT_GNU_ABI_TAG ELF note in the DSOs; the note format is not
> subject to overflows because it uses 32-bit values for the component
> versions.
>
> glibc uses the current kernel's LINUX_VERSION_CODE for two purposes: for
> its own “kernel too old” check (glibc refuses to start in this case),
> and to skip loading DSOs which have an ELF_NOTE_ABI/NT_GNU_ABI_TAG that
> indicates a higher kernel version than the current kernel. glibc does
> not use LINUX_VERSION_CODE to detect features or activate workarounds
> for kernel bugs.
>
> The overflow from 4.9.256 to 4.10.0 means that we might get spurious
> passes on these checks. Worst case, it can happen that if the system
> has a DSO in two versions on the library search path, one for kernel
> 4.10 and one for kernel 4.9 or earlier (in that order), we now load the
> 4.10 version on a 4.9 kernel. Previously, loading the 4.10 DSO failed,
> and the fallback version for earlier kernels was used. That would be
> real breakage.
>
> Our options in userspace are limited because whatever changes we make to
> glibc today are unlikely to reach people running 4.4 or 4.9 kernels
> anytime soon, if ever. Clamping the sublevel field of
> LINUX_VERSION_CODE in the vDSO to 255 only benefits dynamically linked
> binaries, but it could be that this is sufficient to paper over this
> issue.
>
> There's also the question whether these glibc checks are valuable at
> all. It encourages kernel patching to lie about kernel versions, making
> diagnostics harder (e.g., reporting 3.10 if it's really a 2.6.32 with
> lots of system call backports). The ELF_NOTE_ABI/NT_GNU_ABI_TAG DSO
> selection is known to cause endless problems with Qt, basically the only
> large-scale user of this feature. Perhaps we should remove it, but it
> would also break the fallback DSO approach mentioned above.
Thank you for looking into this. Based on the above, I think we are
safe by keeping the LINUX_VERSION_CODE maxed out at 255, and still
increasing the kernel version number itself (which will be returned by
uname(2).)
I have a report of Android systems parsing the uname(2) string output,
and treating the minor number as an 8bit number, but luckily the
decision based on that will not overflow until 5*256 so we are ok for a
few more years on older Android systems :)
If you run into any reports of problems, please let us know.
thanks again,
greg k-h