From: Joel Granados <j.granados@samsung.com>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Kees Cook <keescook@chromium.org>,
Eric Dumazet <edumazet@google.com>,
Dave Chinner <david@fromorbit.com>,
<linux-fsdevel@vger.kernel.org>, <netdev@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-s390@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-riscv@lists.infradead.org>, <linux-mm@kvack.org>,
<linux-security-module@vger.kernel.org>, <bpf@vger.kernel.org>,
<linuxppc-dev@lists.ozlabs.org>, <linux-xfs@vger.kernel.org>,
<linux-trace-kernel@vger.kernel.org>,
<linux-perf-users@vger.kernel.org>,
<netfilter-devel@vger.kernel.org>, <coreteam@netfilter.org>,
<kexec@lists.infradead.org>, <linux-hardening@vger.kernel.org>,
<bridge@lists.linux.dev>, <lvs-devel@vger.kernel.org>,
<linux-rdma@vger.kernel.org>, <rds-devel@oss.oracle.com>,
<linux-sctp@vger.kernel.org>, <linux-nfs@vger.kernel.org>,
<apparmor@lists.ubuntu.com>
Subject: Re: [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers
Date: Wed, 8 May 2024 13:40:38 +0200 [thread overview]
Message-ID: <20240508114038.vnx2hchpxeimuqz2@joelS2.panther.com> (raw)
In-Reply-To: <4cda5d2d-dd92-44ef-9e7b-7b780ec795ab@t-8ch.de>
[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]
On Fri, May 03, 2024 at 04:09:40PM +0200, Thomas Weißschuh wrote:
> Hey Joel,
>
...
> > # Motivation
> > As I read it, the motivation for these constification efforts are:
> > 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. Compiler optimizations: This was just a comment in the patchsets that I have
> > mentioned ([3,4,5]). Do you know what optimizations specifically? Does it
> > have to do with enhancing locality for the data in .rodata? Do you have other
> > specific optimizations in mind?
>
> I don't know about anything that would make it faster.
> It's more about safety and transmission of intent to API users,
> especially callback implementers.
Noted.
...
> > # Show the move
> > I created [8] because there is no easy way to validate which objects made it
> > into .rodata. I ran [8] for your Dec 2nd patcheset [7] and there are less in
> > .rodata than I expected (the results are in [9]) Why is that? Is it something
> > that has not been posted to the lists yet?
>
> Constifying the APIs only *allows* the actual table to be constified
> themselves.
> Then each table definition will have to be touched and "const" added.
That is what I thought. thx for clarifying.
>
> See patches 17 and 18 in [7] for two examples.
>
> Some tables in net/ are already "const" as the static definitions are
> never registered themselves but only their copies are.
>
...
best
--
Joel Granados
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
prev parent reply other threads:[~2024-05-08 11:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20240423075608eucas1p265e7c90f3efd6995cb240b3d2688b803@eucas1p2.samsung.com>
2024-04-23 7:54 ` [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 01/11] stackleak: don't modify ctl_table argument Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 02/11] cgroup: bpf: constify ctl_table arguments and fields Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 03/11] hugetlb: constify ctl_table arguments of utility functions Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 04/11] utsname: constify ctl_table arguments of utility function Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 05/11] neighbour: " Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 06/11] ipv4/sysctl: constify ctl_table arguments of utility functions Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 07/11] ipv6/addrconf: " Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 08/11] ipv6/ndisc: constify ctl_table arguments of utility function Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 09/11] ipvs: constify ctl_table arguments of utility functions Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 10/11] sysctl: constify ctl_table arguments of utility function Thomas Weißschuh
2024-04-23 7:54 ` [PATCH v3 11/11] sysctl: treewide: constify the ctl_table argument of handlers Thomas Weißschuh
2024-04-29 9:47 ` Heiko Carstens
2024-04-23 18:31 ` [PATCH v3 00/11] sysctl: treewide: constify ctl_table argument of sysctl handlers Luis Chamberlain
2024-04-25 3:12 ` Jakub Kicinski
2024-04-25 7:10 ` Thomas Weißschuh
2024-04-27 7:40 ` Thomas Weißschuh
2024-04-25 11:04 ` Joel Granados
2024-04-25 20:34 ` Thomas Weißschuh
2024-05-08 11:37 ` Joel Granados
2024-05-08 17:11 ` Kees Cook
2024-05-09 1:00 ` Jakub Kicinski
2024-05-11 9:51 ` Thomas Weißschuh
2024-05-12 19:32 ` Joel Granados
2024-05-13 2:57 ` Kees Cook
2024-05-12 19:24 ` Joel Granados
2024-05-03 9:03 ` Joel Granados
2024-05-03 14:09 ` Thomas Weißschuh
2024-05-08 11:40 ` Joel Granados [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240508114038.vnx2hchpxeimuqz2@joelS2.panther.com \
--to=j.granados@samsung.com \
--cc=apparmor@lists.ubuntu.com \
--cc=bpf@vger.kernel.org \
--cc=bridge@lists.linux.dev \
--cc=coreteam@netfilter.org \
--cc=david@fromorbit.com \
--cc=edumazet@google.com \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sctp@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lvs-devel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=rds-devel@oss.oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).