linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

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: <20150424105047.GA24894@pd.tnic>
Date:	Fri, 24 Apr 2015 12:50:48 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Daniel Mack <daniel@...que.org>
Cc:	Steven Noonan <steven@...inklabs.net>,
	David Herrmann <dh.herrmann@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
	Andy Lutomirski <luto@...capital.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

Hi,

On Fri, Apr 24, 2015 at 12:28:54PM +0200, Daniel Mack wrote:
> Sure, for broadcasts, we have to walk the list of peers connected to the
> bus and see which one is interested in a particular message. We do that

And this "... we have to walk the list ..." right there raises the
alarm. Can this walking of elements where you know they wouldn't match
be avoided?

> by looking at the match rules of each of them, which are based on
> well-known names, IDs, notification types or bloom filters. The policy
> logic limits this further, as receivers of a broadcast must have TALK
> access to the sender.

So it sounds to me like there are characteristics which can already
prepare lists of recipients interested in some sort of message. So
would it be possible for recipients to "register" for such messages
and the sending side would simply iterate a list of solely interested
recipients?

This will definitely save you the iteration over all n connections and
would make the metadata collection probably not needed (or at least a
subset of it) because recipients will have to establish eligibility for
receiving a certain message at register time and once they're on the
list, you implicitly know why they're there.

I don't know whether that fits all use cases but it definitely does only
the *necessary* work for message transfer and not more.

> If these rules let a message pass, all the metadata that the receiving
> peer asked for (by setting a flag at connect time) is collected, unless
> it has been collected already for some other peer for the same message.
> In other words, in worst case, we collect all the metadata items exactly
> once per message.

Right.

> If none of the connections with permissive match/policy rules for a
> message is interested in any metadata items, nothing will be collected
> at all.

But we still iterate through there and look at the arg @what and
->collected. And this is useless work which can be avoided IMHO.

> If the receiving side doesn't need it, it shouldn't opt-in for that
> piece of information.
> 
> The metadata logic is really only there so receiving peers are directly
> supplied with information that they would otherwise look up themselves
> from /proc or something. Also, we collect metadata at send time and for
> every message intentionally, so that it reflects the state of the sender
> at the time of sending. This way, the information is not subject to
> races of asynchronous lookups.

Ok.

> > Now, one might argue that you have to do O(n) work when broadcasting
> > to n recipients anyway and you can't get that cheaper but maybe the
> > design is not optimal. Maybe it could be made to not broadcast at all,
> > or broadcast to a subset of recipients, only those which are actually
> > interested in the broadcast.
> 
> That's exactly what happens :) There are some more details on this in
> kdbus.match(7).

But this is not for KDBUS_DST_ID_BROADCAST types, right? Because there
you have to iterate over *all* recipients in the connection hash.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/