| 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
| ||
|
Message-ID: <CAEntwhGzWpndmrorjkePZ1nkV6Ei_p-iSRavAbWhMGdfzfW-kA@mail.gmail.com> Date: Wed, 15 Apr 2015 12:44:44 -0400 From: Havoc Pennington <hp@...ox.com> To: Rik van Riel <riel@...hat.com> Cc: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 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 Wed, Apr 15, 2015 at 12:00 PM, Rik van Riel <riel@...hat.com> wrote: > 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 When trying to split apart problems, for dbus it's important to keep ordering guarantees. That is, with dbus if I send a broadcast message, then send a unicast request to another client, then drop the connection causing the bus to broadcast that I've dropped; then the other client will see those things in that order - the broadcast, then the request, and then that I've dropped the connection. If you have separate facilities for these things, it could get hard to keep them in order. dbus uses the simple model that they stay in order because the bus conceptually has a single dispatch queue. By pushing everything through one queue, dbus is trying to reduce the number of codepaths in applications. Apps have a lot of new problems to solve if messages get their order scrambled. (dbus does NOT guarantee order across multiple clients, of course - there's no guarantee that all clients get the broadcast, before anyone gets the next message - each client has its own buffer on both read and write. The ordering is only with respect to each client's message stream.) Ordering is vital for tracking state, because if you're sending out events to describe changes in state, the order of those changes is important. Of course there are more complex ways to handle this over in distributed-systems-world. Havoc -- 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/
Powered by blists - more mailing lists