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]
Date:	Mon, 26 Oct 2009 10:05:50 +0200
From:	Gilad Ben-Yossef <gilad@...efidence.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Bill Fink <billfink@...dspring.com>,
	William Allen Simpson <william.allen.simpson@...il.com>,
	netdev@...r.kernel.org,
	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Subject: Re: [PATCH v2 8/8] Document future removal of sysctl_tcp_* options

Eric Dumazet wrote:

> Bill Fink a écrit :
>   
>> On Sun, 25 Oct 2009, Gilad Ben-Yossef wrote:
>>
>>     
>>> Eric Dumazet wrote:
>>>
>>>
>>> I still think having a global kill switch and per route options better 
>>> (basically use the exiting patch but not retire the global kill 
>>> switch|), but if you must Hgow about we leave the global sysctl as they 
>>> are and just have a two bit route option:
>>>
>>> 0 Use global default
>>> 1 Off
>>> 2 On
>>>
>>> It's kind of funny, because this is what the original patch from 
>>> Comsleep does and I thought it needlessly complicates things.
>>>
>>> So, what do you say - which will it be?
>>>       
>> I personally feel the 2-bit settings are overkill.  What i think
>> makes the most sense is for the global options to act as they always
>> have in the absence of any route specific settings, and for any
>> route specific settings to override the related global settings.
>> This is both simple and maintains backward compatibility.
>>     
>
> Backward compatibility is important, very important, if not the most
> important thing. Then usability comes.
>   
I tend to agree.
> I know some busy servers where adding/changing a single route makes them
> go crazy (because of ip route flush cache)
>
> So if a route is overriding a global conf, and the admin wants to make an
> emergency change during peak hours, he should do it by a global setting,
> or he wont use at all this new stuff, and stay conservative.
>
> Alternative would be to not trigger the flush of cache when changing
> features flags.
>
>   
OK. It really sounds like we should go with my first suggestion: global 
sysctl based kill switches, just as we have now and in addition, the 
ability to kill TCP options per route. The TCP option will be used if 
and only if both kill switches (global and per route) are not set.

What we achieve is:

1. Global kill switches work exactly as they do now, whether you use the 
new per route options or not, so backwards compatible.

2. In addition, if the global kill switch is not in effect, you can also 
kill the options on a per route basis.

I'm going to send third version of the patch to this effect, minus the 
new remote DoS possibility that Ilpo pointed out and leaving the global 
sysctl kill switches be.

If you like it, please ACK ;-)

Thanks,
Gilad



-- 
Gilad Ben-Yossef
Chief Coffee Drinker & CTO
Codefidence Ltd.

Web:   http://codefidence.com
Cell:  +972-52-8260388
Skype: gilad_codefidence
Tel:   +972-8-9316883 ext. 201
Fax:   +972-8-9316884
Email: gilad@...efidence.com

Check out our Open Source technology and training blog - http://tuxology.net

	"Linux is Ir. Ir, of course, is a form of hypereviscerated Reiyk."
		-- Marc Volovic, linux-il, 14 Dec 2000

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ