Dbus-Broker 28 Released

[pkunk]

I’ve always been curious about what the performance of these actually means for the end user

On https://www.linuxfoundation.org/blog...-linux-kernel/

The existing AF_BUS patches are great for users who need a very low-latency, high-speed, D-Bus protocol on their system. This includes the crazy automotive Linux developers, who try to shove tens of thousands of D-Bus messages through their system at boot time, all while using extremely underpowered processors.

About this people:

https://www.genivi.org/

https://www.youtube.com/watch?v=9Xrqm6qAEqw

[computerquip]

Bug in KDBUS = Buffer overflow = Exploit and since KDBUS runs in kernel space = Potential privilege escalation

Oh boy, do I have something to tell you about monolithic kernels...

[cl333r]

I’ve always been curious about what the performance of these actually means for the end user

Not quite the right answer but:
I've been curious myself, so, I had recently a task I could 2 two ways: with dbus and without (finding all mounted/unmounted partitions and their size and mount points)
- with DBus it took 16ms
- without - 0.5 ms (by reading /proc/mounts and /sys/block/sda(nvme)/*)

So the DBus version was 32 times slower than querying the OS directly, so there's quite a need for BUS1, apps like ktorrent should become more responsive.

[intelfx]

Bug in KDBUS = Buffer overflow = Exploit and since KDBUS runs in kernel space = Potential privilege escalation

Bug in D-Bus or dbus-broker = Buffer overflow = D-Bus runs in user space and on its own user = No privilege escalation

And?
When people are talking about security risks, they usually mean nontrivial risks.
It is a truism that more software means more bugs. Under your definition, any (privileged) software is a security risk, thus your definition is useless.

Also, you are incorrect.
Bug in D-Bus (any implementation) = buffer overflow = exploit = attacker gains control over the bus = attacker sends requests to privileged daemons = privilege escalation.

It does reinvent the wheel since D-Bus already exists and BUS1 is a completely unrelated thing.
On the other hand, dbus-broker keeps compatibility

Well exactly, BUS1 is a completely unrelated thing, thus it does not "reinvent" anything.
Is shared memory a "reinvention of the wheel" given named pipes and sockets exist?

[uid313]

So IPC is built when you want to build a system with different components running in different processes instead of all in one process?
Also when you want to build one application that runs stand alone but can interact with another application built by someone else?

But if you want you rely on D-Bus, dbus-broker, or BUS1 then your application only works on Linux. If you rely on Binder, then it only works on Android. If you want to do cross-platform then you have to use anonymous pipe or named pipe and send something like Protobuf?
Like you have a pseudo file that is not a real file, and you read and write to it from multiple processes?
Or you have like a network daemon that broadcast and relays things to each connected socket, like a message bus, but local?

[stalkerg]

I think Broker should be the only active project:

1. KDBUS poses a security risk
2. BUS1 means reinventing the wheel and therefore having to rewrite every application

only when Broker will support non systemd systems like Gentoo OpenRC, Deuvan and *BSD

[coder]

if you want you rely on D-Bus, dbus-broker, ... then your application only works on Linux.

First of all, where did you ever get the idea that D-Bus is Linux-specific? It's been available on lots of platforms, virtually since its inception. Even Windows!

Second, D-Bus is both a protocol definition and a reference implementation. DBus-Broker is an alternate implementation (and maybe indeed Linux-specific, for all I know), but implements the same protocol -- which is why it's a drop-in replacement for the reference dbus daemon.

[jacob]

So IPC is built when you want to build a system with different components running in different processes instead of all in one process?
Also when you want to build one application that runs stand alone but can interact with another application built by someone else?

But if you want you rely on D-Bus, dbus-broker, or BUS1 then your application only works on Linux. If you rely on Binder, then it only works on Android. If you want to do cross-platform then you have to use anonymous pipe or named pipe and send something like Protobuf?
Like you have a pseudo file that is not a real file, and you read and write to it from multiple processes?
Or you have like a network daemon that broadcast and relays things to each connected socket, like a message bus, but local?

I think that by 2021 multi-platformness is somewhat overvalued. Linux works more or less on anything anywhere, so being Linux only is not really a limiting factor for users. Of course in an ideal world software would be multiplatform and all, but when that comes at the price of disproportionately larger development effort and/or decreased functionality, telling users "just install linux if you want to run this" is IMHO a perfectly valid stance.

[tildearrow]

Well exactly, BUS1 is a completely unrelated thing, thus it does not "reinvent" anything.
Is shared memory a "reinvention of the wheel" given named pipes and sockets exist?

Whatever happened to /dev/shm?

[ssokolow]

Whatever happened to /dev/shm?

To rephrase what intelfx said, "Well exactly. BUS1 is a completely unrelated thing, thus it does not "reinvent" anything. Is /dev/shm a "reinvention of the wheel" because named pipes and sockets already existed?"

...or, if you're comparing BUS1 and /dev/shm, the latter is a much lower-level API.