netdev - Re: [PATCH net-next 0/5] sctp: use transport hashtable to replace association's with rhashtable

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]

Message-ID: <56845AAF.9010204@gmail.com>
Date:	Wed, 30 Dec 2015 20:29:03 -0200
From:	Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>
Cc:	lucien.xin@...il.com, netdev@...r.kernel.org,
	linux-sctp@...r.kernel.org, mleitner@...hat.com,
	vyasevic@...hat.com, daniel@...earbox.net
Subject: Re: [PATCH net-next 0/5] sctp: use transport hashtable to replace
 association's with rhashtable

Em 30-12-2015 19:57, Eric Dumazet escreveu:
> On Wed, 2015-12-30 at 15:44 -0500, David Miller wrote:
>
>> It is more fun than waiting longer for the more limited uses of it to
>> trigger problems.
>>
>> I cannot be convinced that using it in more places in order to find
>> and fix more bugs is a bad thing.
>>
>> I'm sorry if a lot of bug fixes in a short period of time concerns
>> you, but for me that's an even clearer sign that it needs help, and
>> exposing it to more use cases is one of the best forms of help it can
>> get.
>>
>> It also tells me that the people actually working on those fixes, such
>> as Herbert Xu, are motivated and reliable when they are shown properly
>> formed bug reports.
>>
>> I cannot think of a report Herbert and others did not resolve in a
>> timely manner.  They usually add test cases too.
>
>
> I have no doubts we can fix bugs in upstream kernels in a few days (at
> most).
>
> The problem is when a customer is stuck using a distro, with a release
> cycle of extra months after upstream fixes.

If one takes extra months to have a fix delivered to a customer, they 
probably are also months late on security fixes as well, right? That 
would be pretty scary by itself already.

> I had to deal with customers having issues with resolvers hitting the
> netlink/rhashtable bugs, and I can tell you it was not pretty nor funny.
>
> Seeing all these SCTP bugs being currently tracked/fixed (reports from
> Dmitry Vyukov), I am concerned about having to backport fixes into old
> kernels without proper rhashtable if now SCTP relies heavily on
> rhashtable.

This happens with every major change in the kernel. Try backporting 
vxlan fixes to an older kernel, for example, to one without ip_tunnel.

Can't say about the future, but so far none of those bugs were related 
to the hash that we want to replace and they were all small/contained 
patches.

And at least for now, we are not adding new stuff which relies on this 
new hash. It's on a central part of sctp, yes, but somewhat contained. 
Like what happened with vxlan/ip_tunnel, which ended up growing together.

> Hopefully nothing bad will happen.

+1 :)

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