linux-hardening - Re: [PATCH v2 00/18] sysctl: constify sysctl ctl

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: <46d68741-0ac8-47cc-a28f-bf43575e68a1@t-8ch.de>
Date: Fri, 15 Dec 2023 17:40:59 +0100
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: Joel Granados <j.granados@...sung.com>, 
	Dan Carpenter <dan.carpenter@...aro.org>, Julia Lawall <julia.lawall@...ia.fr>, 
	Kees Cook <keescook@...omium.org>, "Gustavo A. R. Silva" <gustavoars@...nel.org>, 
	Iurii Zaikin <yzaikin@...gle.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v2 00/18] sysctl: constify sysctl ctl_tables

On 2023-12-12 23:51:30-0800, Luis Chamberlain wrote:
> On Tue, Dec 12, 2023 at 10:09:30AM +0100, Joel Granados wrote:
> > My idea was to do something similar to your originl RFC, where you have
> > an temporary proc_handler something like proc_hdlr_const (we would need
> > to work on the name) and move each subsystem to the new handler while
> > the others stay with the non-const one. At the end, the old proc_handler
> > function name would disapear and would be completely replaced by the new
> > proc_hdlr_const.
> > 
> > This is of course extra work and might not be worth it if you don't get
> > negative feedback related to tree-wide changes. Therefore I stick to my
> > previous suggestion. Send the big tree-wide patches and only explore
> > this option if someone screams.
> 
> I think we can do better, can't we just increase confidence in that we
> don't *need* muttable ctl_cables with something like smatch or
> coccinelle so that we can just make them const?

The fact that the code compiles should be enough, no?
Any funky casting that would trick the compiler to accept it would
probably also confuse any other tool.

> Seems like a noble endeavor for us to generalize.
> 
> Then we just breeze through by first fixing those that *are* using
> mutable tables by having it just de-register and then re-register
> new tables if they need to be changed, and then a new series is sent
> once we fix all those muttable tables.

Ack. But I think the actual constification should really only be started
after the first series for the infrastructure is in.

Thomas