linux-kernel - Re: Current state of the sysctl constification effort

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]

Date: Fri, 7 Jun 2024 15:54:01 +0200
From: Thomas Weißschuh <thomas@...ch.de>
To: Joel Granados <j.granados@...sung.com>
Cc: Luis Chamberlain <mcgrof@...nel.org>, linux-kernel@...r.kernel.org, 
	Kees Cook <keescook@...omium.org>
Subject: Re: Current state of the sysctl constification effort

On 2024-06-07 11:40:53+0000, Joel Granados wrote:
> On Fri, May 31, 2024 at 12:50:32PM +0200, Thomas Weißschuh wrote:
> > Hi Joel, Hi Luis,
> > 
> > most of the sysctl handler preparation patches have been picked up by
> > the subsystem maintainers and are available in -next.
> > 
> > Only two are missing:
> > 
> > * utsname: constify ctl_table arguments of utility function [0]
> > * sysctl: constify ctl_table arguments of utility function [1]
> > 
> > Both of them are going through the sysctl tree anyways.
> > 
> > With this done it should be possible to also queue up 
> > sysctl: treewide: constify the ctl_table argument of handlers [2]
> > for the bots to chew on in -next.
> > 
> > My local builds are still succeeding on the last submitted version of
> > the patch.
> > 
> > 
> > Thomas
> > 
> > [0] https://lore.kernel.org/lkml/20240518-sysctl-const-handler-utsname-v1-1-27a6c8813620@weissschuh.net/
> > [1] https://lore.kernel.org/lkml/20240513-jag-constfy_sysctl_proc_args-v1-1-bba870a480d5@samsung.com/
> > [2] https://lore.kernel.org/lkml/20240423-sysctl-const-handler-v3-11-e0beccb836e2@weissschuh.net/
> 
> All this is coming together nicely.

Indeed.

> Is there anything left to do besides
> what is being discussed in this mail, to start changing the ctl_tables
> to `static const`?

The changes to the tables also need (as per [0] and [1]):

* sysctl: move internal interfaces to const struct ctl_table
* sysctl: allow registration of const struct ctl_table

I think we do the handlers for v6.11, the rest of [0] and [1] for v6.12
and then we can go through the rest of the trees ctl_tables.


[0] https://lore.kernel.org/lkml/20231204-const-sysctl-v2-0-7a5060b11447@weissschuh.net/
[1] https://git.sr.ht/~t-8ch/linux/log/sysctl-constfy