Dbus-Broker 19 Released With Fixes For This Speedy D-Bus User-Space Implementation

[phoronix]

Phoronix: Dbus-Broker 19 Released With Fixes For This Speedy D-Bus User-Space Implementation

With BUS1 not to be found (or rather, very infrequently seeing any code commits let alone any clear trajectory yet for getting into the mainline kernel), Dbus-Broker that's worked on by most of the same developers continues maturing as a high-performance D-Bus compliant user-space implementation...

http://www.phoronix.com/scan.php?page=news_item&px=Dbus-Broker-19-Released

[Ananace]

I thought the plan was to develop an efficient user-space implementation of DBus (dbus-broker) first, before properly starting work on a kernel implementation. (BUS1)

At least it seemed like that was the goal from reading the reasons why KDBus was finally rejected.

[tildearrow]

I thought the plan was to develop as efficient an user-space implementation of DBus (dbus-broker) first, before properly starting work on BUS1

Why would they work on a bus nobody would ever use? (by "bus" I mean BUS1)

[Candy]

I thought the plan was to develop as efficient an user-space implementation of DBus (dbus-broker) first, before properly starting work on BUS1

The plan is, that everything has to come from Red Hat. If this is not the case, then it ends up being a NIH scenario. The second step would be agressive marketing, so that the stuff is being showed down your throath - as with any stuff coming from Red Hat. Be it SystemD, Pulseaudio, Flatpak and other unnecessary stuff.

[jacob]

Why would they work on a bus nobody would ever use? (by "bus" I mean BUS1)

I think a kernel-based implementation is what we ultimately need though. If only because it would be subject to standard access control, confinement, containerisation and auditing mechanisms.

[tildearrow]

I think a kernel-based implementation is what we ultimately need though. If only because it would be subject to standard access control, confinement, containerisation and auditing mechanisms.

Isn't having a bus in the kernel actually less secure?

[jacob]

Isn't having a bus in the kernel actually less secure?

I don't know why, unless you think that a kernel-based filesystem is inherently less secure than a FUSE-based one, or that a kernel-based TCP/IP stack is less secure than a pure userland implementation.

[xpue]

kernel-based filesystem is inherently less secure

Thats why microkernels exist. Userspace program which reads filesystems like "archives" will be more secure than FUSE. Problem is, such approach hurts performance.

[jacob]

Thats why microkernels exist. Userspace program which reads filesystems like "archives" will be more secure than FUSE. Problem is, such approach hurts performance.

Actually FUSE is the exact microkernel approach, based on interprocess messaging. An in-process library-style implementation is possible of course, typically that's what all the fsck.XXX tools use. But it's not true that something is more secure just because it's in userspace. Userspace code can, in principle, not corrupt the rest of the OS, but...

* the filesystem driver itself can get corrupted either way, being in userspace makes that no less nor more likely than a kernel driver
* an userspace approach presents greater challenges in terms of synchronisation, race conditions etc
* an userspace approach cannot be audited using the generic kernel mechanisms, its use can't be subjected to access control, it can't be confined using apparmor or selinux or seccomp etc.
* on the other hand if it's to implement any security features of its own, these are much more difficult to enforce from userspace than from within the kernel

Microkernels have advantages but also disadvantages, and not just in terms of performance. And since developing kernel code is more difficult than userspace, and yet people decide to do it for things so complex as filesystems, it's because there are very good reasons for it.

[Ananace]

why did you think that?



your two sentences are exclusive or

To paraphrase Linus's answer to the kdbus merge discussion - https://lkml.org/lkml/2015/6/23/657

"No kernel-side bus is going to be accepted for performance increasing reasons, until there's a user-space implementation that actually hits the performance barrier."

After this point, the kdbus project stopped, and BUS1 appeared as the predecessor. But no work really begun on that, as instead they started working on the user-space side dbus-broker as well.

So seeing as they're working on a user-space bus that's more performant, I'd expect them to continue that project until they get to the point where it requires a kernel component to improve performance and security - which it doesn't at the current moment. And at that point, I expect work on BUS1 to pick up, not before.


But of course, this is just my assumptions from reading the mailing list and looking at what's happening, I've not actually asked any of the developers about the plans.