Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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?pag...er-19-Released

  • #2
    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.
    Last edited by Ananace; 03-29-2019, 07:33 PM.

    Comment


    • #3
      Originally posted by Ananace View Post
      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)

      Comment


      • #4
        Originally posted by Ananace View Post
        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.

        Comment


        • #5
          Originally posted by tildearrow View Post

          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.

          Comment


          • #6
            Originally posted by jacob View Post

            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?

            Comment


            • #7
              Originally posted by tildearrow View Post

              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.

              Comment


              • #8
                Originally posted by jacob View Post
                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.

                Comment


                • #9
                  Originally posted by xpue View Post
                  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.

                  Comment


                  • #10
                    Originally posted by hreindl View Post

                    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.

                    Comment

                    Working...
                    X