linux-kernel - Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL

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: <20210118153135.GA4035784@sasha-vm>
Date:   Mon, 18 Jan 2021 10:31:35 -0500
From:   Sasha Levin <sashal@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     masahiroy@...nel.org, michal.lkml@...kovi.net,
        torvalds@...ux-foundation.org, linux-kbuild@...r.kernel.org,
        linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: [PATCH] kbuild: give SUBLEVEL more room in KERNEL_VERSION

On Mon, Jan 18, 2021 at 02:52:02PM +0100, Greg KH wrote:
>On Mon, Jan 18, 2021 at 08:39:59AM -0500, Sasha Levin wrote:
>> I think it would also affect code that doesn't do things based on
>> SBULEVEL. Consider something like:
>>
>> 	if (LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0))
>>
>> Which will cause 4.4.256 to now change the result of that comparison.
>
>Sure, but there are no in-kernel users like this, so my sympathy is
>quite low :)

Wouldn't it be an issue for the hacky in-kernel users too? For example,
right now the USB code does:

	#define KERNEL_REL      bin2bcd(((LINUX_VERSION_CODE >> 16) & 0x0ff))
	#define KERNEL_VER      bin2bcd(((LINUX_VERSION_CODE >> 8) & 0x0ff))

After 4.4.256, KERNEL_VER will be (5) rather than (4), indicating a
version of 4.5.

-- 
Thanks,
Sasha