All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wen Yang <wen.yang@linux.dev>
To: Joel Granados <joel.granados@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Christian Brauner <brauner@kernel.org>,
	Dave Young <dyoung@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5] sysctl: simplify the min/max boundary check
Date: Thu, 6 Mar 2025 21:33:39 +0800	[thread overview]
Message-ID: <806ee13d-cb97-4c27-b645-763c02b51713@linux.dev> (raw)
In-Reply-To: <qpuf3nepmmkiqt7spcdpyrdnbyzbztr3jgabwou7bjyl746czs@c2iimb3bekr4>



On 2025/3/3 17:26, Joel Granados wrote:
> On Thu, Jan 30, 2025 at 10:32:14PM +0800, Wen Yang wrote:
>>
>>
>> On 2025/1/28 01:51, Eric W. Biederman wrote:
>>> Joel Granados <joel.granados@kernel.org> writes:
>>>
>>>> On Thu, Jan 23, 2025 at 12:30:25PM -0600, Eric W. Biederman wrote:
>>>>> "Eric W. Biederman" <ebiederm@xmission.com> writes:
>>>>>
>>>>>> Joel Granados <joel.granados@kernel.org> writes:
>>>>>>
>>>>>>> On Sun, Jan 19, 2025 at 10:59:21PM +0800, Wen Yang wrote:
> ...
>>>> struct ctl_table {
>>>> 	const char *procname;		/* Text ID for /proc/sys */
>>>> 	void *data;
>>>> 	int maxlen;
>>>> 	umode_t mode;
>>>> 	proc_handler *proc_handler;	/* Callback for text formatting */
>>>> 	struct ctl_table_poll *poll;
>>>>         unsigned long min;
>>>>         unsigned long max;
>>>> } __randomize_layout;
>>>
>>> That is just replace extra1 and extra2 with min and max members.  The
>>> members don't have any reason to be pointers.  Without being pointers
>>> the min/max functions can just use long values to cap either ints or
>>> longs, and there is no room for error.  The integer promotion rules
>>> will ensure that even negative values can be stored in unsigned long
>>> min and max values successfully.  Plus it is all bog standard C
>>> so there is nothing special to learn.
>>>
>>> There are a bunch of fiddly little details to transition from where we
>>> are today.  The most straightforward way I can see of making the
>>> transition is to add the min and max members.  Come up with replacements
>>> for proc_doulongvec_minmax and proc_dointvec_minmax that read the new
>>> min and max members.  Update all of the users.  Update the few users
>>> that use extra1 or extra2 for something besides min and max.  Then
>>> remove extra1 and extra2.  At the end it is simpler and requires the
>>> same or a little less space.
>>>
>>> That was and remains my suggestion.
>>>
>>
>> Thanks for your valuable suggestions. We will continue to move forward along
>> it and need your more guidance.
>>
>> But there are also a few codes that do take the extra{1, 2} as pointers, for
>> example:
>>
>> int neigh_sysctl_register(struct net_device *dev, struct neigh_parms *p,
>>                            proc_handler *handler)
>> {
>> ...
>>          for (i = 0; i < NEIGH_VAR_GC_INTERVAL; i++) {
>>                  t->neigh_vars[i].data += (long) p;
>>                  t->neigh_vars[i].extra1 = dev;
>>                  t->neigh_vars[i].extra2 = p;
>>          }
>> ...
>> }
>>
>> static void neigh_proc_update(const struct ctl_table *ctl, int write)
>> {
>>          struct net_device *dev = ctl->extra1;
>>          struct neigh_parms *p = ctl->extra2;
>>          struct net *net = neigh_parms_net(p);
>>          int index = (int *) ctl->data - p->data;
>> ...
>> }
> Quick question: Do you have a systemic way of identifying these? Do you
> have a grep or awk scripts somewhere? I'm actually very interested in
> finding out what is the impact of this.
> 

Thanks, we may use the following simple scripts:

- the extra {1,2} as pointers to some objects:
$ grep "\.extra1\|\.extra2" * -R | grep -v "SYSCTL_" | grep -v "\&"

- the extra {1,2} as pointers to elements in the shared constant array:
$ grep "\.extra1\|\.extra2" * -R | grep "SYSCTL_"

- the extra {1,2} as pointers to additional constant variables:
$ grep "\.extra1\|\.extra2" * -R | grep "\&"


--
Best wishes,
Wen


> 
> 
>>
>>
>> So could we modify it in this way to make it compatible with these two
>> situations:
>>
>> @@ -137,8 +137,16 @@ struct ctl_table {
>>          umode_t mode;
>>          proc_handler *proc_handler;     /* Callback for text formatting */
>>          struct ctl_table_poll *poll;
>> -       void *extra1;
>> -       void *extra2;
>> +       union {
>> +               struct {
>> +                       void *extra1;
>> +                       void *extra2;
>> +               };
>> +               struct {
>> +                       unsigned long min;
>> +                       unsigned long max;
>> +               };
>> +       };
>>   } __randomize_layout;
>>
>>
>> --
>> Best wishes,
>> Wen
>>
> 

  reply	other threads:[~2025-03-06 13:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-05 15:28 [PATCH v5] sysctl: simplify the min/max boundary check Wen Yang
2025-01-16  9:37 ` Joel Granados
2025-01-19 14:59   ` Wen Yang
2025-01-22 12:57     ` Joel Granados
2025-01-23 18:13       ` Eric W. Biederman
2025-01-23 18:30         ` Eric W. Biederman
2025-01-27 13:34           ` Joel Granados
2025-01-27 17:51             ` Eric W. Biederman
2025-01-30 14:32               ` Wen Yang
2025-02-27 14:09                 ` Joel Granados
2025-12-19 14:44                   ` Joel Granados
2025-12-19 18:10                     ` Wen Yang
2025-12-22 21:59                       ` Joel Granados
2025-03-03  9:26                 ` Joel Granados
2025-03-06 13:33                   ` Wen Yang [this message]
2025-03-10 14:25                     ` Joel Granados
2025-03-12 14:54                       ` Wen Yang
2025-02-27 14:07               ` Joel Granados
2025-03-01  3:49                 ` Wen Yang

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=806ee13d-cb97-4c27-b645-763c02b51713@linux.dev \
    --to=wen.yang@linux.dev \
    --cc=brauner@kernel.org \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=joel.granados@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.