linux-kernel - Re: Revisit AF_BUS: is it a better way to implement KDBUS?

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:	Thu, 30 Jul 2015 11:12:44 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	cee1 <fykcee1@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Lennart Poettering <lennart@...ttering.net>,
	David Herrmann <dh.herrmann@...il.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Subject: Re: Revisit AF_BUS: is it a better way to implement KDBUS?

On Thu, Jul 30, 2015 at 6:09 AM, cee1 <fykcee1@...il.com> wrote:
> Hi all,
>
> I'm interested in the idea of AF_BUS.
>
> There have already been varies discussions about it:
> * Missing the AF_BUS - https://lwn.net/Articles/504970/
> * Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel -
> http://lwn.net/Articles/537021/
> * presentation-kdbus -
> https://github.com/gregkh/presentation-kdbus/blob/master/kdbus.txt
> * Re: [GIT PULL] kdbus for 4.1-rc1 - https://lwn.net/Articles/641278/
> * The kdbuswreck - https://lwn.net/Articles/641275/
>
> I'm wondering whether it is a better way, that is, a general mechanism
> to implement varies __Bus__ orientated IPCs, such as Binder[1],
> DBus[2], etc.

I find myself wondering whether an in-kernel *bus* is a good idea at
all.  Creating a bus that unprivileged programs are allowed to
broadcast on (which is kind of the point) opens up big cans of worms.
Namely: what happens when producers produce data faster than the
consumers consume it?  Keep in mind that, with a bus, this scales
pretty badly.  Each producer's sends are multiplied by the number of
participants.

At some point soon, I'm planning on playing with Fedora Rawhide with
kdbus.  Anything's possible (maybe), but I'd be rather surprised if it
holds up under abuse of the bus.

ISTM kdbus is trying to solve a few problems that really can't be
solved together: it wants (mostly) reliable delivery, it wants
globally ordered messages, and it wants broadcasts.  That means that,
if message N gets broadcast, then, until *every* recipient has
received message N, message N and all of its successors need to be
buffered somewhere.  I see how this works (by massive use of tmpfs),
but I don't see how it's going to work *well*.

Certainly approximate solutions are possible, but is the kernel really
a good place to arbitrate which message survive under pressure?

People can throw code at this all they want, but ISTM the problem that
the dbus community wants to solve doesn't actually admit a scalable
solution.

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