linux-kernel - Re: [GIT PULL] sysctl changes for v6.11-rc1

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] [day] [month] [year] [list]

Message-ID: <20240813205204.c4na3lcdhvqfiz4d@joelS2.panther.com>
Date: Tue, 13 Aug 2024 22:52:04 +0200
From: Joel Granados <j.granados@...sung.com>
To: Solar Designer <solar@...nwall.com>
CC: Linus Torvalds <torvalds@...ux-foundation.org>, Luis Chamberlain
	<mcgrof@...nel.org>, Jeff Johnson <quic_jjohnson@...cinc.com>, Kees Cook
	<keescook@...omium.org>, Thomas Wei??schuh <linux@...ssschuh.net>, Wen Yang
	<wen.yang@...ux.dev>, <linux-kernel@...r.kernel.org>,
	<linux-fsdevel@...r.kernel.org>
Subject: Re: [GIT PULL] sysctl changes for v6.11-rc1

On Tue, Aug 06, 2024 at 08:57:37PM +0200, Solar Designer wrote:
> On Tue, Jul 16, 2024 at 04:16:56PM +0200, Joel Granados wrote:
> > sysctl changes for 6.11-rc1
> > 
> > Summary
> > 
> > * Remove "->procname == NULL" check when iterating through sysctl table arrays
> > 
> >     Removing sentinels in ctl_table arrays reduces the build time size and
> >     runtime memory consumed by ~64 bytes per array. With all ctl_table
> >     sentinels gone, the additional check for ->procname == NULL that worked in
> >     tandem with the ARRAY_SIZE to calculate the size of the ctl_table arrays is
> >     no longer needed and has been removed. The sysctl register functions now
> >     returns an error if a sentinel is used.
> > 
> > * Preparation patches for sysctl constification
> > 
> >     Constifying ctl_table structs prevents the modification of proc_handler
> >     function pointers as they would reside in .rodata. The ctl_table arguments
> >     in sysctl utility functions are const qualified in preparation for a future
> >     treewide proc_handler argument constification commit.
> 
> As (I assume it was) expected, these changes broke out-of-tree modules.
> For LKRG, I am repairing this by adding "#if LINUX_VERSION_CODE >=
> KERNEL_VERSION(6,11,0)" checks around the corresponding module changes.
> This works.  However, I wonder if it would possibly be better for the
> kernel to introduce a corresponding "feature test macro" (or two, for
> the two changes above).  I worry that these changes (or some of them)
> could get backported to stable/longterm, which with the 6.11+ checks
> would unnecessarily break out-of-tree modules again (and again and again
> for each backport to a different kernel branch).  Feature test macro(s)
> would avoid such further breakage, as they would (be supposed to be)
> included along with the backports.
> 
> Joel, Linus, or anyone else - what do you think?  And in general, would
As mentioned by Thomas; These changed must not be backported and
therefore there is not concern about backport consequences.

> it be a good practice for Linux to be providing feature test macros to
> indicate this sort of changes?  Is there a naming convention for them?
I don't think that would be a good practice. IMO, a good way to handle
these things in out-of-tree modules is the LINUX_VERSION_CODE hack. You
can see it here for the same reason :
https://github.com/cryptodev-linux/cryptodev-linux/commit/99ae2a39ddc3f89c66d9f09783b591c0f2dbf2e9
...

Best

-- 

Joel Granados