netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH next] sysctl: add proc_dointvec_jiffies_minmax to limit the min/max write value
       [not found]   ` <d5138655-41a8-0177-ae0d-c4674112bf56@huawei.com>
@ 2019-05-15 17:06     ` Kees Cook
  2019-06-04 15:27       ` Zhiqiang Liu
  0 siblings, 1 reply; 4+ messages in thread
From: Kees Cook @ 2019-05-15 17:06 UTC (permalink / raw)
  To: Zhiqiang Liu
  Cc: mcgrof, linux-kernel, linux-fsdevel, ebiederm, pbonzini, viro,
	adobriyan, mingfangsen, wangxiaogang3, Zhoukang (A),
	netdev, akpm

On Wed, May 15, 2019 at 10:53:55PM +0800, Zhiqiang Liu wrote:
> Friendly ping...
> 
> 在 2019/4/24 12:04, Zhiqiang Liu 写道:
> > 
> > Friendly ping...

Hi!

(Please include akpm on CC for next versions of this, as he's likely
the person to take this patch.)

> > 
> >> From: Zhiqiang Liu <liuzhiqiang26@huawei.com>
> >>
> >> In proc_dointvec_jiffies func, the write value is only checked
> >> whether it is larger than INT_MAX. If the write value is less
> >> than zero, it can also be successfully writen in the data.

This appears to be "be design", but I see many "unsigned int" users
that might be tricked into giant values... (for example, see
net/netfilter/nf_conntrack_standalone.c)

Should proc_dointvec_jiffies() just be fixed to disallow negative values
entirely? Looking at the implementation, it seems to be very intentional
about accepting negative values.

However, when I looked through a handful of proc_dointvec_jiffies()
users, it looks like they're all expecting a positive value. Many in the
networking subsystem are, in fact, writing to unsigned long variables,
as I mentioned.

Are there real-world cases of wanting to set a negative jiffie value
via proc_dointvec_jiffies()?

> >>
> >> However, in some scenarios, users would adopt the data to
> >> set timers or check whether time is expired. Generally, the data
> >> will be cast to an unsigned type variable, then the negative data
> >> becomes a very large unsigned value, which leads to long waits
> >> or other unpredictable problems.
> >>
> >> Here, we add a new func, proc_dointvec_jiffies_minmax, to limit the
> >> min/max write value, which is similar to the proc_dointvec_minmax func.
> >>
> >> Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
> >> Reported-by: Qiang Ning <ningqiang1@huawei.com>
> >> Reviewed-by: Jie Liu <liujie165@huawei.com>

If proc_dointvec_jiffies() can't just be fixed, where will the new
function get used? It seems all the "unsigned int" users could benefit.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH next] sysctl: add proc_dointvec_jiffies_minmax to limit the min/max write value
  2019-05-15 17:06     ` [PATCH next] sysctl: add proc_dointvec_jiffies_minmax to limit the min/max write value Kees Cook
@ 2019-06-04 15:27       ` Zhiqiang Liu
  2019-07-01  8:06         ` Zhiqiang Liu
  2019-07-02 19:32         ` Luis Chamberlain
  0 siblings, 2 replies; 4+ messages in thread
From: Zhiqiang Liu @ 2019-06-04 15:27 UTC (permalink / raw)
  To: Kees Cook, akpm
  Cc: mcgrof, linux-kernel, linux-fsdevel, ebiederm, pbonzini, viro,
	adobriyan, mingfangsen, wangxiaogang3, Zhoukang (A),
	netdev, netdev

> On Wed, May 15, 2019 at 10:53:55PM +0800, Zhiqiang Liu wrote:
> 
> (Please include akpm on CC for next versions of this, as he's likely
> the person to take this patch.)
Thanks for your advice. And sorry to reply you so late.

>>>> In proc_dointvec_jiffies func, the write value is only checked
>>>> whether it is larger than INT_MAX. If the write value is less
>>>> than zero, it can also be successfully writen in the data.
> 
> This appears to be "be design", but I see many "unsigned int" users
> that might be tricked into giant values... (for example, see
> net/netfilter/nf_conntrack_standalone.c)
> 
> Should proc_dointvec_jiffies() just be fixed to disallow negative values
> entirely? Looking at the implementation, it seems to be very intentional
> about accepting negative values.
> 
> However, when I looked through a handful of proc_dointvec_jiffies()
> users, it looks like they're all expecting a positive value. Many in the
> networking subsystem are, in fact, writing to unsigned long variables,
> as I mentioned.
> 
I totally agree with you. And I also cannot find an scenario that expects
negative values. Consideing the "negative" scenario may be exist, I add the
proc_dointvec_jiffies_minmax like proc_dointvec_minmax.

> Are there real-world cases of wanting to set a negative jiffie value
> via proc_dointvec_jiffies()?
Until now, I do not find such cases.

>>>>
>>>> Here, we add a new func, proc_dointvec_jiffies_minmax, to limit the
>>>> min/max write value, which is similar to the proc_dointvec_minmax func.
>>>>
> 
> If proc_dointvec_jiffies() can't just be fixed, where will the new
> function get used? It seems all the "unsigned int" users could benefit.
> 
I tend to add the proc_dointvec_jiffies_minmax func to provide more choices and
not change the previous use of proc_dointvec_jiffies func.

Thanks for your reply again.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH next] sysctl: add proc_dointvec_jiffies_minmax to limit the min/max write value
  2019-06-04 15:27       ` Zhiqiang Liu
@ 2019-07-01  8:06         ` Zhiqiang Liu
  2019-07-02 19:32         ` Luis Chamberlain
  1 sibling, 0 replies; 4+ messages in thread
From: Zhiqiang Liu @ 2019-07-01  8:06 UTC (permalink / raw)
  To: Kees Cook, akpm
  Cc: mcgrof, linux-kernel, linux-fsdevel, ebiederm, pbonzini, viro,
	adobriyan, mingfangsen, wangxiaogang3, Zhoukang (A),
	netdev

friendly ping ...

On 2019/6/4 23:27, Zhiqiang Liu wrote:
>> On Wed, May 15, 2019 at 10:53:55PM +0800, Zhiqiang Liu wrote:
>>
>> (Please include akpm on CC for next versions of this, as he's likely
>> the person to take this patch.)
> Thanks for your advice. And sorry to reply you so late.
> 
>>>>> In proc_dointvec_jiffies func, the write value is only checked
>>>>> whether it is larger than INT_MAX. If the write value is less
>>>>> than zero, it can also be successfully writen in the data.
>>
>> This appears to be "be design", but I see many "unsigned int" users
>> that might be tricked into giant values... (for example, see
>> net/netfilter/nf_conntrack_standalone.c)
>>
>> Should proc_dointvec_jiffies() just be fixed to disallow negative values
>> entirely? Looking at the implementation, it seems to be very intentional
>> about accepting negative values.
>>
>> However, when I looked through a handful of proc_dointvec_jiffies()
>> users, it looks like they're all expecting a positive value. Many in the
>> networking subsystem are, in fact, writing to unsigned long variables,
>> as I mentioned.
>>
> I totally agree with you. And I also cannot find an scenario that expects
> negative values. Consideing the "negative" scenario may be exist, I add the
> proc_dointvec_jiffies_minmax like proc_dointvec_minmax.
> 
>> Are there real-world cases of wanting to set a negative jiffie value
>> via proc_dointvec_jiffies()?
> Until now, I do not find such cases.
> 
>>>>>
>>>>> Here, we add a new func, proc_dointvec_jiffies_minmax, to limit the
>>>>> min/max write value, which is similar to the proc_dointvec_minmax func.
>>>>>
>>
>> If proc_dointvec_jiffies() can't just be fixed, where will the new
>> function get used? It seems all the "unsigned int" users could benefit.
>>
> I tend to add the proc_dointvec_jiffies_minmax func to provide more choices and
> not change the previous use of proc_dointvec_jiffies func.
> 
> Thanks for your reply again.
> 
> 
> .
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH next] sysctl: add proc_dointvec_jiffies_minmax to limit the min/max write value
  2019-06-04 15:27       ` Zhiqiang Liu
  2019-07-01  8:06         ` Zhiqiang Liu
@ 2019-07-02 19:32         ` Luis Chamberlain
  1 sibling, 0 replies; 4+ messages in thread
From: Luis Chamberlain @ 2019-07-02 19:32 UTC (permalink / raw)
  To: Zhiqiang Liu
  Cc: Kees Cook, akpm, linux-kernel, linux-fsdevel, ebiederm, pbonzini,
	viro, adobriyan, mingfangsen, wangxiaogang3, Zhoukang (A),
	netdev

On Tue, Jun 04, 2019 at 11:27:51PM +0800, Zhiqiang Liu wrote:
> > On Wed, May 15, 2019 at 10:53:55PM +0800, Zhiqiang Liu wrote:
> >>>> In proc_dointvec_jiffies func, the write value is only checked
> >>>> whether it is larger than INT_MAX. If the write value is less
> >>>> than zero, it can also be successfully writen in the data.
> > 
> > This appears to be "be design", but I see many "unsigned int" users
> > that might be tricked into giant values... (for example, see
> > net/netfilter/nf_conntrack_standalone.c)
> > 
> > Should proc_dointvec_jiffies() just be fixed to disallow negative values
> > entirely? Looking at the implementation, it seems to be very intentional
> > about accepting negative values.
> > 
> > However, when I looked through a handful of proc_dointvec_jiffies()
> > users, it looks like they're all expecting a positive value. Many in the
> > networking subsystem are, in fact, writing to unsigned long variables,
> > as I mentioned.
> > 
> I totally agree with you. And I also cannot find an scenario that expects
> negative values. Consideing the "negative" scenario may be exist, I add the
> proc_dointvec_jiffies_minmax like proc_dointvec_minmax.

If no negative values exist, and there is no real point to it, then just
rename the existing one and update the docs.

  Luis

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-07-02 19:32 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <032e024f-2b1b-a980-1b53-d903bc8db297@huawei.com>
     [not found] ` <3e421384-a9cb-e534-3370-953c56883516@huawei.com>
     [not found]   ` <d5138655-41a8-0177-ae0d-c4674112bf56@huawei.com>
2019-05-15 17:06     ` [PATCH next] sysctl: add proc_dointvec_jiffies_minmax to limit the min/max write value Kees Cook
2019-06-04 15:27       ` Zhiqiang Liu
2019-07-01  8:06         ` Zhiqiang Liu
2019-07-02 19:32         ` Luis Chamberlain

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).