netdev - Re: [PATCH 0/10] af_unix: add multicast and filtering features to AF

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] [day] [month] [year] [list]

Message-ID: <20120305185502.GF3119316@jupiter.n2.diac24.net>
Date:	Mon, 5 Mar 2012 19:55:03 +0100
From:	David Lamparter <equinox@...c24.net>
To:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
Cc:	David Miller <davem@...emloft.net>, shemminger@...tta.com,
	ying.xue@...driver.com, luiz.dentz@...il.com,
	eric.dumazet@...il.com, rodrigo.moya@...labora.co.uk,
	javier@...labora.co.uk, lennart@...ttering.net,
	kay.sievers@...y.org, alban.crequy@...labora.co.uk,
	bart.cerneels@...labora.co.uk, sjoerd.simons@...labora.co.uk,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/10] af_unix: add multicast and filtering features to
 AF_UNIX

On Fri, Mar 02, 2012 at 10:27:16AM +0100, Javier Martinez Canillas wrote:
> Do you think that a simpler AF_UNIX multicast implementation without the
> locking to guarantee order delivery and the flow control that blocks the
> sender can be resend to you to reconsider merging it?

I still don't get how blocking the sender when the receiver doesn't
empty his socket queue can possibly ever be a good idea. All I see is a
very nice way to choke the entire D-Bus from one malicious or broken
app.

Note that originally we were talking about blocking delivery for
_multicast_. In that case you can't even poll on writability on a
granularity finer than group level.

Yet, this still comes up here and there as a requirement for IPC
mechanisms to back D-Bus.

When the buffers at the receiver are fully filled, IMHO that's the point
to cut off the client. If this becomes an issue, the buffers can be
increased in size, but at some point it's a sign that you're using D-Bus
for too much?

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