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: <20231217120201.z4gr3ksjd4ai2nlk@localhost>
Date: Sun, 17 Dec 2023 13:02:01 +0100
From: Joel Granados <j.granados@...sung.com>
To: Luis Chamberlain <mcgrof@...nel.org>
CC: Dan Carpenter <dan.carpenter@...aro.org>, Julia Lawall
	<julia.lawall@...ia.fr>, Kees Cook <keescook@...omium.org>, Thomas
	Weißschuh <linux@...ssschuh.net>, "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

Catching up with mail....

On Tue, Dec 12, 2023 at 11:51:30PM -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?
>
> 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
So let me see if I understand your {de,re}-register idea:
When we have a situation (like in the networking code) where a ctl_table
is being used in an unmuttable way, we do your {de,re}-register trick.

The trick consists in unregistering an old ctl_table and reregistering
with a whole new const changed table. In this way, whatever we register
is always const.

Once we address all the places where this happens, then we just change
the handler to const and we are done.

Is that correct?

If that is indeed what you are proposing, you might not even need the
un-register step as all the mutability that I have seen occurs before
the register. So maybe instead of re-registering it, you can so a copy
(of the changed ctl_table) to a const pointer and then pass that along
to the register function.

Can't think of anything else off the top of my head. Would have to
actually see the code to evaluate further I think.

> new tables if they need to be changed, and then a new series is sent
> once we fix all those muttable tables.
> 
>   Luis

best

-- 

Joel Granados

Download attachment "signature.asc" of type "application/pgp-signature" (660 bytes)