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: <20150415150658.0b33410c@lxorguk.ukuu.org.uk>
Date:	Wed, 15 Apr 2015 15:06:58 +0100
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Jiri Kosina <jkosina@...e.cz>, Al Viro <viro@...IV.linux.org.uk>,
	Borislav Petkov <bp@...en8.de>,
	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tom Gundersen <teg@...m.no>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

> operating systems anymore.  Those "legacy" oses provide a system bus
> that allows them to send thousands of queries just fine, but when moving
> to Linux, we don't have anything other than D-Bus, so their library is
> ported to use it, and they have to handle their old applications that
> need/want the zillions of messages.

And if you look at those systems btw many of them have a very compact,
very clean very simple message passing interface,often in the hundreds
not tens of thousands of lines of code.

> People take those stateless models and build stateful ones on top of
> them, yes, it's great.  But you still need a stateful model somewhere in
> order to be able to achieve many things (think a shopping cart
> application).

We put the IP stack in the kernel not the shopping cart. A good shopping
cart of course only has state on the client.

> Anyway, this is getting off-topic, there is very little "state" in the
> kdbus kernel code here, other than a naming database that Havoc and
> Simon explain the need for, and the normal lifecycle of kdbus "nodes"
> (new, linked, active, inactive, drained, freed).

I'm not convinced the naming data belongs in kernel beyond the simplest
of "node 147". I'd offer a sort of proof by armwaving of this that if you
have


/dev/dbus/014   /dev/dbus/027 etc

you can add a symlink to /dev/dbus/014 of

/dev/dbus-by-name/gnome-wombat-grooming-daemon

or whatever

and we do that today for every other naming database and static
allocation we've spent the past 15 years evicting from the kernel.

That state isn't then held in a daemon that can crash nor is it invisible
to debuggers, user tools and admins.

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