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/[email protected]/
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.
Indeed. These are going to go into sysctl-next as soon as I get around
to creating the branch (this week, if all goes well :)
>
> 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.
Indeed, and I have also tested it in the kernel test bots through my
kernel.org repos. So this is no surprise.
>
>
> 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/[email protected]/
--
Joel Granados
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/[email protected]/
All this is coming together nicely. Is there anything left to do besides
what is being discussed in this mail, to start changing the ctl_tables
to `static const`?
Best
--
Joel Granados
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/[email protected]/
>
> 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/[email protected]/
[1] https://git.sr.ht/~t-8ch/linux/log/sysctl-constfy
On Fri, Jun 07, 2024 at 03:54:01PM +0200, Thomas Wei?schuh wrote:
> 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:
...
> > 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.
LGTM. Once you send "sysctl: move internal interfaces to const struct ctl_table" and
"sysctl: allow registration of const struct ctl_table", I'll put them
into sysctl-testing and have them there until they can go into sysctl-next
(after the end of the next merge window). Please send both of them in one
series and remember to work on the "what" and the "why" for the commit
messages and cover letter.
You can be inspired by this
"""
# Motivation
The reason we are constifying is:
1. It provides increased safety: Having things in .rodata section reduces the
attack surface. This is especially relevant for structures that have function
pointers (like ctl_table); having these in .rodata means that these pointers
always point to the "intended" function and cannot be changed.
2. Readability: because it is easier to know up-front that data is not supposed
to change or its obvious that a function is re-entrant. Actually a lot of the
readability reasons is about knowing things "up-front".
As we move forward with the constification in sysctl, please include a more
detailed motivation in all your cover letters. This helps maintainers (that
don't have the context) understand what you are trying to do.
"""
Best
--
Joel Granados
On 2024-06-10 10:10:36+0000, Joel Granados wrote:
> On Fri, Jun 07, 2024 at 03:54:01PM +0200, Thomas Weißschuh wrote:
> > 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:
> ...
> > > 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.
>
> LGTM. Once you send "sysctl: move internal interfaces to const struct ctl_table" and
> "sysctl: allow registration of const struct ctl_table", I'll put them
> into sysctl-testing and have them there until they can go into sysctl-next
> (after the end of the next merge window). Please send both of them in one
> series and remember to work on the "what" and the "why" for the commit
> messages and cover letter.
IMO all of the remaining commits can go in as one series, as they all
belong to the sysctl core
(I can leave out "sysctl: constify standard sysctl tables")
FYI recent changes to the sysctl core introduced another prerequisite
for "sysctl: move internal interfaces to const struct ctl_table", which
is "bpf: Constify ctl_table argument of filter function".
See https://git.kernel.org/pub/scm/linux/kernel/git/thomas.weissschuh/linux.git/ sysctl-constfy
Thomas