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: <552E8B11.4010803@redhat.com>
Date:	Wed, 15 Apr 2015 12:00:17 -0400
From:	Rik van Riel <riel@...hat.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:	Jiri Kosina <jkosina@...e.cz>,
	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

On 04/15/2015 07:06 AM, One Thousand Gnomes wrote:

>> that anyone here does either.  In the many years I've spent working on
>> this, dbus has seemed to be odd, and strange, to the way that the kernel
>> has normally worked, because it is.  And that's not a bad thing, it's
>> just different, and for us to support real needs and requirements of our
>> users, is the requirement of the Linux kernel.
> 
> There are I think a set of intertwined problems here
> 
> - An efficient delivery system for multicast messages delivered locally
>   (be that MPI, dbus whatever - it's not "dbus or nothing")
> 
> - A kernel side dynamic namespace to describe what goes where
> 
> - A kernel side security model to describe who may receive what, and
>   which additional information/tags/cred info
> 
> - Something that provides state to stuff that needs it (and probably
>   belongs in userspace - dbus name service etc)
> 
> - Something that maps dbus and other models onto the kernel security
>   model (and we have tools like EBPF which are very powerful)
> 
> - Something that maps the kernel layer onto models like MPI-3

It is not clear to me why user space applications would
have to change if the kernel bus used for dbus behaves
differently from the userspace dbus daemon.

Can't libdbus take care of the differences, and remove
some of the problems highlighted by Alan (eg. the possibility
of the protocol requiring the kernel to keep more messages
in flight than we have memory for) ?

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