[PATCH 0/5] RFC: Multicast and filtering features on AF_UNIX

[Alban Crequy]

Le Mon, 27 Sep 2010 17:56:30 +0200,
Lennart Poettering <mzqohf at 0pointer.de> a écrit :

> 1;2591;0cOn Mon, 27.09.10 16:03, Alban Crequy
> (alban.crequy at collabora.co.uk) wrote:
> 
> > setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, ...) checks and
> > attaches the BPF to the socket successfully both on AF_INET and
> > AF_UNIX. But in practice, sk_run_filter() is never called on
> > AF_UNIX. I tried to attach a BPF to a SOCK_STREAM AF_UNIX socket
> > and whatever my BPF is, I can still receive everything on the
> > socket. I guess it could be implemented if it is found useful.
> 
> Hmm, not sure it makes a lot of sense to use a packet filter on a
> non-dgram socket. However, I expected that BSD socket filters would
> work just fine on AF_UNIX/SOCK_DGRAM. If they don't, then it is
> probably a good idea to fix that. And my (uneducated) guess is that
> it would be relatively easy.

Indeed, it is about 7 lines of code to add the support of socket
filters in AF_UNIX :)

http://git.collabora.co.uk/?p=user/alban/linux-2.6.35.y/.git;a=commitdiff;h=7d5116bc34922c51e6ef8db2f4d8e69250f06cc2;hp=9511f0d2731603afe6a50c1ed866ce1e3fc4b2b0

It makes sense to have socket filters on SOCK_SEQPACKET because it
preserve the packet boundaries. And it does not cost anything to add it
to SOCK_STREAM too.

> > Is there any real use of BSD socket filters on a non-AF_NETLINK
> > socket?
> 
> Off the top of my head I know only wireshark/tcpdump, libudev, ping,
> dhcpcd who use them, but I guess a google code search should reveal
> more. Of those listed I think udev is the only one using them on
> AF_NETLINK and everybody else uses them on AF_INET/SOCK_RAW, but I
> might be wrong on that.
> 
> > Do you suggest to put these additional hashes in the header of D-Bus
> > messages sent by userspace D-Bus peers (hence modifying the D-Bus
> > protocol)?
> 
> Well, you need to modify the protocol anyway if you use SOCK_DGRAM
> instead of SOCK_STREAM as transport. And if you do that a few fixed
> size hash fields in the prefix shouldn't hurt.

With the current implementation of dbus-daemon, when a message is
received by dbus-daemon, it checks only the match rules with the correct
(type, interface) because the match rules are stored in a lookup table
by type and interface (implemented by another awesome dude in bug fd.o
#23117). All match rules should contain a type and interface criteria
in order to benefit from this, and in practice it is mostly true (and
when it's not, it can easily be fixed). Will said in commitlog
b4264cb0e66aea2e56b414a529024c35f6a0d90f:

   «In my informal studies of "normal" sets of match rules, only
    checking match rules with the appropriate interface for the message
    reduces the number that need to be checked by almost 100x on
    average (ranging from halving for messages from the bus daemon, to
    a >200x reduction in many cases). This reduces the overhead added
    to dispatching each message by having lots of irrelevant match
    rules.»


If match rule implementation in dbus-daemon is replaced by socket
filters in the kernel, the kernel would need to check n socket filters,
where n is the number of D-Bus peers. I'm not sure whether
the dbus-daemon implementation or socket filters in kernel would be
better.

If a D-Bus connection has 4 match rules (it looks a reasonable pattern):
- type=type1, interface=iface1, member=member1
- type=type1, interface=iface1, member=member2
- type=type1, interface=iface2
- type=type1, interface=iface3

We could imagine to have 2 different bloom filters (with 2 new fields
in the headers):

1. One to represent the set of match rules containing a type and an
   interface (the hash function will take type+interface as input)

2. One to represent the set of match rules containing a type, an
   interface and a member (the hash function will take type+interface
   +member as input)

And the socket filter will let a message pass if it passes any of the
bloom filters.

> [...]

Alban