LWN: Comments on "The kdbuswreck"

The kdbuswreck

shentino — Wed, 13 May 2015 21:43:29 +0000

Don't unix domain sockets support passing process credentials as out of band data?

If I remember the man page right you can pass pid, uid, gid, and open fds

The kdbuswreck

dgm — Mon, 04 May 2015 07:58:25 +0000

> the scheduler should've been altered to also select the previous process' IPC peer ("partner") to run until the client's wakeup condition was satisfied, and then return to the client immediately. This would've made a closed wait over AF_UNIX equivalent to a syscall, some thousands of clock cycles notwithstanding.

Hear! Hear!

This has the potential to make requesting services from a daemon (any daemon) much more efficient. Everything from web servers to desktop environments could benefit. Just think about how many daemons are constantly running in any typical desktop (answer: dozens!)

One has to wonder why something like this doesn't exists yet?

The kdbuswreck

cesarb — Thu, 30 Apr 2015 20:00:39 +0000

> And even memfd isn't required for that. Anybody heared of mmap() ?

The point of using a memfd is that it can be sealed, so there's no risk of a TOCTOU vulnerability in the receiver.

With mmap(), the sender can change what the receiver sees while the receiver is looking at it.

The kdbuswreck

ms_43 — Thu, 30 Apr 2015 18:25:58 +0000

You should not confuse POSIX.1e capabilities, as implemented by Linux, with the capabilities described in security research literature for many years, which are quite precisely defined (and I really wonder why the POSIX committee used that term).

Linux also has *those* capabilities (in a very limited form), they are just called "file descriptors".

The closest you're going to get to a capability-based security model with a traditional UNIX-like kernel is Capsicum.

http://lwn.net/Articles/482858/

(Insert standard rant about kids these days thinking that "operating system" is a synonym for UNIX)

The kdbuswreck

kentonv — Thu, 30 Apr 2015 17:04:32 +0000

> * make the FDs/sockets/... appear in the process' filesystem (using per-process namespaces)

Why? All this does is potentially create new security holes: if you can trick the app into opening an arbitrary file, you can now make it open one of its own FDs too, possibly bypassing chroot environments, etc. (This is in fact already possible through /proc/self, of course.)

> * separate services by security domains (so, choose the granularity of the service operations in a way that you either allowed to talk to the service or not)

No, that's the opposite of capability-based security. This is access control lists, with which it's notoriously difficult to express complex security policies because as the ACLs become more granular the maintenance burden skyrockets.

In capability-based security, you simply give a process capabilities (file descriptors) for the resources it needs to do its job and not for things it doesn't need. Essentially, you can define new "security domains" on-the-fly by specifying a set of capabilities.

> * let processes pass these fd's selectively to others

Unix domain sockets!

> * instead of sockets (streams), use directory trees (like in /sys)

If the goal is to put everything in one directory tree, then, again, you're creating a global namespace which creates risk of confused deputy attacks. OTOH, if you are allowed to have lots of different directory trees where you can give someone access to a particular tree by passing them a file descriptor and using openat() style calls, great. But I think trying to shoehorn arbitrary interfaces into looking like directories tends to create ugly interfaces. I want data types and function calls, not strings and read/write.

> * add an simple but generic remote file system for that

???

> Finally, you'll have something like Plan9 or Inferno ...

Sorry, they don't sound like what I want at all.

The kdbuswreck

ksandstr — Thu, 30 Apr 2015 16:01:17 +0000

>Secondly, AFAIR, the current dbus daemon gets penalized by fair kernel scheduling. That issue goes away with kdbus.

The issue should've gone away when priority inheritance was mooted for AF_UNIX to support lower latency in Xorg: the scheduler should've been altered to also select the previous process' IPC peer ("partner") to run until the client's wakeup condition was satisfied, and then return to the client immediately. This would've made a closed wait over AF_UNIX equivalent to a syscall, some thousands of clock cycles notwithstanding.

It's my opinion that a transitive form of partner scheduling and priority inheritance would've made an userspace DBus daemon near-transparent from a performance point-of-view, were a sufficient "counts as partner call" boundary possible to distinguish from the many states and forms of I/O sleep found in Unix. However today, instead of a relatively simple and well-defined primitive behaviour (and perhaps a tiny control API to manage it), we have 10_000 lines of lennartware being pushed for inclusion -- and not in staging like Android's "binder", either.

And before someone else in our little peanut gallery chimes in about priority inheritance: while that is necessary for a well-performing IPC architecture, it's insufficient a solution to the whole of the latency issue because rather than re-using the abstract scheduling decision that made a client process run in the first place, it only elevates the recipient's priority. A scheduler may well schedule an unrelated process in the server's (elevated) priority band, for example. The inheritance mechanism's interactions with scheduling quantums (the server's? the client's? at what priority? for how long?) and its teardown conditions have also remained poorly defined, which suggests that these issues just cold-up aren't being considered.

Finally, to not call "lennartware" without justification, and based on the considerations above, it's my prediction that if kdbus is merged, there'll be a span of two to six years immediately afterward at the end of which that which remains of kdbus-2015 will not be a net loss to its applications anymore, as with PulseAudio and Avahi before that.

The kdbuswreck

ksandstr — Thu, 30 Apr 2015 14:29:27 +0000

Simply put, the idea with capabilities was that a process that has root privileges shouldn't be able to do all that root can, but instead just a narrow slice thereof. This restricts setuid binaries to privileges required for their stated purpose, and nothing else. The desired upshot is a limitation of the damage from successful compromise of setuid binaries and (restrictable) processes otherwise running as root.

It likely didn't help that academia at the time was still mildly abuzz with capability-based this and capability-based that, and that the relevant research papers would read like exercises in ontological wank -- for example, calling a process' knowledge of a path name a "capability" as it makes the process capable of accessing that entry (or discovering that it cannot). While that way of looking at things does account for things like forking (which implicitly copies data such as pathnames), it has precious little to do with the split-root capability mechanism of Linux besides having a word in common and an application in the field of access control.

Historically, then, a "capability" can mean basically everything, which makes it a good word for marketing towards the uncritical and unwary much like "the cloud". [Imagine a snarky remark wrt implied corporate braindamage in systemd here.]

The kdbuswreck

metux-its — Thu, 30 Apr 2015 10:54:38 +0000

Well, extending the FD approach a little bit:

* make the FDs/sockets/... appear in the process' filesystem
(using per-process namespaces)
* separate services by security domains (so, choose the granularity of
the service operations in a way that you either allowed to talk
to the service or not)
* let processes pass these fd's selectively to others
* instead of sockets (streams), use directory trees (like in /sys)
* add an simple but generic remote file system for that

Finally, you'll have something like Plan9 or Inferno ...

The kdbuswreck

metux-its — Thu, 30 Apr 2015 10:44:38 +0000

At this point, I'd rather raise the question, what's _actual_ problem to solve ? Some practical real-world usecases ?

Things like allowing certain (otherwise unprivileged) processes or users to trigger a shutdown (via the init system, of course) can be easily done with traditional unix mechanisms. No need for caps, nor dbus.

The kdbuswreck

metux-its — Thu, 30 Apr 2015 10:23:32 +0000

And even memfd isn't required for that.

Anybody heared of mmap() ? ;-o

The kdbuswreck

metux-its — Thu, 30 Apr 2015 10:17:16 +0000

Actually, I never understood why tiny side cases like reboots need all that complexity.

Anybody noticed that we already have per-process namespaces ?
Oh, and we've got file permission flags since aeons.

Why not just giving things like the shutdown/reboot service their
own communication channel (ie. socket), which is only made available
to certain users or processes ? Either via perms or mounts, or by
some key authentication ?

Anybody had a look at Plan9 ?
It really could be so simple ...

The kdbuswreck

paulj — Wed, 29 Apr 2015 16:57:27 +0000

Quite possible. ;)

To be honest, I'd prefer if this was done with something more generic, i.e. multi-listener AF_UNIX-like and whatever new SCM_CRED stuff needed to support authentication, so that it could benefit now just DBus but also whichever IPC system ends up replacing DBus.

Attaching and exposing kernel capabilities to sockets by default in a new API definitely sounds scarey!

The kdbuswreck

Uraeus — Wed, 29 Apr 2015 16:35:18 +0000

If that is your takeaway from this article I think you probably suffer from confirmation bias :)

The kdbuswreck

granquet — Tue, 28 Apr 2015 14:15:10 +0000

>Secondly, AFAIR, the current dbus daemon gets penalized by fair kernel scheduling. That issue goes away with kdbus. Lastly I think that it's prety clear that kdbus unlocks a whole new level of performance with code based on memfd that current dbus doesn't use.

yes, I concur here.
The switch to the CFS broke some use cases at the place I was working at that time.

but probably, those use cases where a bit stupid ;)

The kdbuswreck

paulj — Tue, 28 Apr 2015 08:23:10 +0000

I wish LWN had a "+1 Awesome" button.

Kdbus looks like the mother of all premature optimisation from this.

The kdbuswreck

javispedro — Tue, 28 Apr 2015 08:10:26 +0000

It introduces a bunch of additional problems. For example, what if you want the same process to expose more than one instance of the service? You will be hit by the fact that despite having multiple service names you still have one object namespace only... and no way to setup different policies, etc.

The MPRIS trick obviously works, but it puts the design of DBus upside down.

The kdbuswreck

luto — Tue, 28 Apr 2015 07:07:41 +0000

I realize that a dbus-like design (central daemon relaying messages) will probably take a performance hit due to context switches and copies. However, there's no reason that a synchronous method call should need 15 context switches, nor is there any reason that dbus couldn't use memfd for large messages.

Regardless, this particular dbus benchmark is so incredibly slow that none of this explains it, and kdbus is apparently only twice as fast. I'm not sure what the problem is, but it's not the scheduler or the fact that there's a central daemon.

IOW, yes, kdbus is in principle twice as fast as a dbus-like design. But dbus is several hundred times slower than it should be. Let's fix that first before quibbling over the other factor of two by moving some or all of it into the kernel.

The kdbuswreck

zyga — Tue, 28 Apr 2015 06:42:03 +0000

The one thing that I think you may be missing is that kdbus-based dbus doesn't do much at all in the userspace deamon. It is the current design that does put all of the overhead in the one userspace process. With the kernel based version half of the overhead is removed outright (A->server->B->server->A becomes A->B->A in the common case).

Secondly, AFAIR, the current dbus daemon gets penalized by fair kernel scheduling. That issue goes away with kdbus. Lastly I think that it's prety clear that kdbus unlocks a whole new level of performance with code based on memfd that current dbus doesn't use.

Still, the threads you've referenced are interesting and I need to read more into them to understand how kdbus-based changes applies to them.

The kdbuswreck

bronson — Tue, 28 Apr 2015 01:13:52 +0000

Maybe 9P failed to learn the WebDAV lesson? If you design a protocol that can be used for everything, nobody will use it.

The kdbuswreck

jspaleta — Tue, 28 Apr 2015 00:46:40 +0000

I thought the first rule of optimization was not to talk about optimization.

The kdbuswreck

dlang — Tue, 28 Apr 2015 00:35:11 +0000

the first rule of optimization, measure first and find your bottleneck

The kdbuswreck

luto — Tue, 28 Apr 2015 00:04:41 +0000

One thing I've learned about software development: never assume that your performance sucks for the reason that you think it sucks. It sure seems obvious that dbus is slow because there's a single process that's a central point of contention. Too bad this doesn't appear to be the case [1] [2].

I can think of a couple reasons that the kernel might be slower than it ought to be for workloads like dbus-daemon. I fixed one of them in 3.16 (it affected me, too). All of this stuff is so far down in the noise, though, that I don't think it's even worth trying to optimize any of the kernel's part yet.

[1] http://lkml.kernel.org/g/CA+55aFxRa3mwL-17hUuUGpjCeGJXseG...
[2] http://lkml.kernel.org/g/CALCETrWLTLqZ0pioOEHakd_S+h=F1X2...

The kdbuswreck

flussence — Mon, 27 Apr 2015 20:44:29 +0000

There's no need for sarcasm; your point is agreeable. X11 *has* improved drastically since most of the X server's functions were moved into the kernel.

The kdbuswreck

lsl — Mon, 27 Apr 2015 18:59:21 +0000

> An interface is implemented by N objects, so for example an interface might be implemented by each open document in a word processor. I would say you do not want "some document that implements the Document interface" when you call `org.whatever.Document.Delete()`, you want the specific document you plan to delete :-)

Ah ok, thanks. Didn't thought about it that way. For most of the stuff on my local system bus it wouldn't make a difference: it doesn't matter who tells me the hostname or who is going to set the timezone. But then there's logind (which I missed the last time), where it in fact matters whose session is going to be terminated.

The kdbuswreck

hp — Mon, 27 Apr 2015 15:17:24 +0000

> That seems backwards to me. Why would I even care what object I talk to? > I just want *some* object that implements the interface I need.

An interface is implemented by N objects, so for example an interface might be implemented by each open document in a word processor. I would say you do not want "some document that implements the Document interface" when you call `org.whatever.Document.Delete()`, you want the specific document you plan to delete :-)

*Services* are generally pluggable - i.e. the entire word processor application, could implement a set of objects (each with a set of interfaces) conforming to some sort of standard, potentially, and then you could interop with whichever word processor owns a certain `org.whatever.WordProcessor` service, or something.

Well-known name: like a DNS entry, a way to find an entire *program* to talk to (service locator)

Object path: equivalent to a pointer ... a specific instance of an object in the "object-oriented programming" sense of object

Interface: means same thing as in Java (set of methods on an object instance)

The fact that some programs have only one object instance with only one interface, in no way means that these are redundant.

Yes you can write a program in Java that only contains `class MyProgram` and `static MyProgram theInstanceOfMyProgram = new MyProgram()`.

This does not mean that Java should _only_ provide support for singleton objects!

The kdbuswreck

MrWim — Mon, 27 Apr 2015 13:28:59 +0000

I don't think it's necessarily an ugly trick. The difference between getting a list of service names with some prefix and in getting a list of services providing some object (assuming this were even possible with D-Bus) is mostly superficial.

If efficiency is the problem, getting a list of service names for things like MPRIS could be optimized by extending the protocol slightly, e.g. by having org.freedesktop.DBus.ListNames take a prefix as an argument.

Indeed, this is the purpose of the arg0namespace match rule. You register for NameOwnerChanged events with some prefix, call ListNames (or ListActivatableNames) filtering on the prefix and then you can efficiently and asynchronously keep your local list of remote names up-to-date.

The kdbuswreck

mchapman — Mon, 27 Apr 2015 12:54:15 +0000

> The "using the service name as what every other IPC would call interface name" idea works well until you realize you cannot register more than one service with the same name. Thus, you start seeing ugly tricks such as what MPRIS does, which require greping over the service names, etc.

I don't think it's necessarily an ugly trick. The difference between getting a list of service names with some prefix and in getting a list of services providing some object (assuming this were even possible with D-Bus) is mostly superficial.

If efficiency is the problem, getting a list of service names for things like MPRIS could be optimized by extending the protocol slightly, e.g. by having org.freedesktop.DBus.ListNames take a prefix as an argument.

But allowing a service name to be owned by at most one connection is essential for lsl's use case. You can't sanely dispatch "to an implementation that makes sense accorrding to local system configuration" if more than one such implementation is on the bus at the same time.

The kdbuswreck

javispedro — Mon, 27 Apr 2015 12:16:15 +0000

> I would say that is *exactly* what D-Bus provides now. There is nothing in D-Bus's policy configuration that locks a service to a particular binary. A service name can be claimed by any process that matches that service's policy (for system services this is typically just a check that the connection was authenticated as root). Of course, only one D-Bus connection can own a service name at any particular time.

You actually _cannot_ do what is being asked with current D-Bus, and it is one of my major gripes with it (which is why I prefer anything else over it). The "using the service name as what every other IPC would call interface name" idea works well until you realize you cannot register more than one service with the same name. Thus, you start seeing ugly tricks such as what MPRIS does, which require greping over the service names, etc.

The kdbuswreck

javispedro — Mon, 27 Apr 2015 12:13:10 +0000

Yes, but you can make symlinks ;)

The kdbuswreck

zyga — Mon, 27 Apr 2015 11:24:46 +0000

Man if only human beings would agree on one specific way to use all of those features so that applications have an inter-operable way of talking to each other. If only that specification got widely implemented and got massive usage in all environments. Then we could see if we could put some of that into the kernel to avoid the one process from having to be the central point of contention. If only someone would have proposed some patches that implement this to the kernel.

The kdbuswreck

mchapman — Mon, 27 Apr 2015 09:16:53 +0000

> I'm going to reiterate what I said in my other post: D-Bus *already provides* the ability for a client to talk to "any object that implements a particular interface": simply replace the word "object" with "service" and "interface" with "object".

Meh, I screwed that comment up. I should have said: simply replace the word "object" with "connection" and "interface" with "service".

That is, a D-Bus client does not care what connection provides a particular service; it relies on bus policy for that to be authorized appropriately.

That being said, I have the feeling there is very little stopping some malicious piece of software from killing off gnome-keyring-daemon, say, and grabbing the org.freedesktop.secrets bus name before GNOME has a chance to restart the daemon.

The kdbuswreck

mchapman — Mon, 27 Apr 2015 09:06:25 +0000

> If you're saving passwords then you want to be sure that the 'org.freedesktop.secrets' address has not been taken by a password-stealing program.

That seems like a completely orthogonal problem to me.

I'm going to reiterate what I said in my other post: D-Bus *already provides* the ability for a client to talk to "any object that implements a particular interface": simply replace the word "object" with "service" and "interface" with "object".

The kdbuswreck

cortana — Mon, 27 Apr 2015 07:30:56 +0000

> That seems backwards to me. Why would I even care what object I talk to? I just want *some* object that implements the interface I need.

If you're saving passwords then you want to be sure that the 'org.freedesktop.secrets' address has not been taken by a password-stealing program.

The kdbuswreck

krake — Mon, 27 Apr 2015 06:45:01 +0000

> That seems backwards to me. Why would I even care what object I talk to? I just want *some* object that implements the interface I need.

It will depend on the type of service, i.e. if there is some object related context.

For example, a service which provides functionality on a set of real world objects will expose these objects again as a set of D-Bus objects.
It makes it easier for programmers on both sides (service and clients) if there is a one-to-one mapping, e.g. NetworkManager exposing each network device as a separate object.

For a service that provides only one interface on one object, the convention seems to be to use the same name parts for the well-known connection name, the object path and the interface name (with respective separator characters).

The kdbuswreck

Cyberax — Mon, 27 Apr 2015 04:12:00 +0000

There's nothing really special about the system bus. It's possible to override it for each application.

But as I understand, it was designed to be a globally visible namespace with access being controlled by PolKit.

The kdbuswreck

bandrami — Mon, 27 Apr 2015 03:44:29 +0000

Man, if only the Kernel team had had the foresight to include things like signals, message queues, semaphores, and shared memory in the first place, we wouldn't need to add a message bus system.

The kdbuswreck

kentonv — Sun, 26 Apr 2015 20:19:50 +0000

The "starting point" would be a file descriptor inherited from the parent process. Today we have "standard input", "standard output", and "standard error"; now imagine adding "standard desktop" which is a socket that implements some protocol to talk to the desktop session.

This file descriptor would support a bunch of standard functionality that all apps need (like, opening windows, or raising notifications, etc., but NOT things where the user might want to choose the resource used or deny it for security reasons, like printers or audio devices or connected OAuth accounts). It would also have a way to say "I need an object (file descriptor) implementing protocol X", and that's when the user is prompted to choose which object to use. Once the user chooses something, the app can save a long-term token representing that choice and re-request the same object later using that token.

Yes, this is "standard desktop" FD is similar to the dbus session bus, except that I can decide which programs that I run are allowed to access it, and I can mock it out, audit usage, sandbox, etc., as described previously, and I can make choices about individual resources accessed by any app.

The kdbuswreck

luto — Sun, 26 Apr 2015 20:17:02 +0000

Not really. Yes, something needs to create a starting point, but that something could just be whatever creates the resource in the first place.

For example, gdm or logind could start my shell with access to an object implementing the "find a printer" interface. Programs that inherit access to that object would use it.

Sandboxed programs, on the other hand, might get access to a different "find a printer" interface that behaves differently.

dbus can do this right now. On my Fedora 21 system, my shell and everything it starts has access to a standard implementation of a lot of these things. It looks like:

DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-qB3T8DFwej,guid=1453a3565ca58487e6a024fe5538ad89

Too bad that doesn't seem to apply to the system bus.

The kdbuswreck

Cyberax — Sat, 25 Apr 2015 22:42:12 +0000

I still have no idea how your design will be any different from the current one. You still need to have well-known starting points for lookups.

The kdbuswreck

kentonv — Sat, 25 Apr 2015 21:03:50 +0000

> Try to watch DBUS with a sniffer. Now imagine that you have to MANUALLY select each and every endpoint.

Yes obviously what I'm describing can't be dropped on top of the existing set of dbus endpoints and just work. Lots of stuff would need to be redesigned and organized differently. It is possible to design such an environment and have it work well (CapDesk did it, and Sandstorm.io is doing it), but I don't honestly expect today's dbus-using desktop environments to entirely switch anytime soon. Still, it's useful for people to understand the ideal in order to guide improvements to what we have today.