Bus1 is the new Kdbus
davmac.wordpress.com
Bus1 is the new Kdbus
1–10 of 18 posts
Re: Bus1 is the new Kdbus
#2Sadly, the author failed to read on the history of kdbus and AF_BUS.
Just using UNIX domain socks is not the solution. This is more or less what dbus currently does and has major issues with memory accounting and trusts.
Re: Bus1 is the new Kdbus
#3I'm kinda surprised that they don't just build a service on top of generic netlink. For those of you who don't know, Netlink has been a generic API for KernelClient communication for some time. The kernel added the ability for modules to register their own generic netlink families that can add another route of kinds for modules to communicate with.
Does anyone know why?
Re: Bus1 is the new Kdbus
#4Biased source.
Selected post titles:
- D-Bus, ConsoleKit, PolicyKit: turds upon turds upon turds
- The Systemd (sic) debacle
- D-Bus is completely unnecesary
Choice quote:
"yes, they want me to call it “systemd”, but I’m averse, for some reason, to proper nouns beginning with lower-case letters; something to do with having had a moderately good education, I guess"
This is reddit-level drivel. Please refrain from posting it.
An LWN article on bus1 will come out, eventually; post that instead.
Re: Bus1 is the new Kdbus
#5Sadly, the author failed to read on the history of kdbus and AF_BUS. Just using UNIX domain socks is not the solution. This is more or less what dbus currently does and has major issues with memory accounting and trusts.
Can you give a brief explanation of that?
It does seem to me that a "pipe with fanout", or similar new type of socket, might be the best way of doing this.
Or if you really want to annoy people, copy the Windows PostMessage() system.
Re: Bus1 is the new Kdbus
#6This is basically just trolling. Poor show.
Re: Bus1 is the new Kdbus
#7I'm kinda surprised that they don't just build a service on top of generic netlink. For those of you who don't know, Netlink has been a generic API for Kernel Client communication for some time. The kernel added the ability for modules to register their own generic netlink families that can add another route of kinds for modules to communicate with. Does anyone know why?
[deleted]
Re: Bus1 is the new Kdbus
#8Sadly, the author failed to read on the history of kdbus and AF_BUS. Just using UNIX domain socks is not the solution. This is more or less what dbus currently does and has major issues with memory accounting and trusts.
Can you give a brief explanation of that? It does seem to me that a "pipe with fanout", or similar new type of socket, might be the best way of doing this. Or if you really want to annoy people, copy the Windows PostMessage() system.
See previous discussion: https://news.ycombinator.com/item?id=12800995
There are various other properties of Bus1 that make it better than all other alternatives, but obviously relying on it makes your program non-portable. IPC is a mess on POSIX systems.
Re: Bus1 is the new Kdbus
#9Judging by this description, Bus1 sounds very much like an object capability system. There is a lot of theoretical and practical evidence that this is a good programming model, and as far as I know it does not currently exist in linux. Maybe you can build a proper object capability system on top of sockets. I don't know enough about unix domain sockets to say if it is really possible to establish the right security guarantees this way, but I'm reasonably sure that whoever is behind Bus1 has investigated this before proposing a new kernel extension. Case in point, the blog post describes a flawed implementation.
What really rubs me the wrong way, though, is all the negativity expressed in this blog post. Also some of the suggestions are downright dangerous. For instance:
> (except that individual connections to a socket can be “revoked” i.e. closed, which is surely an improvement if anything)
This is not an improvement, this is another failure state that you add to every single connection, and which every single client has to handle. You can already implement this feature via proxy objects in a pure object capability system, and in this case you have to be explicit about adding another error state.
> I think this is meant to read as “no, it’s not the D-Bus daemon functionality being subsumed in the kernel”.
I read the preceeding explanation as saying "here is a security guarantee that clients can rely on". What is the alternative? Having unix domain sockets sprinkled somewhere in the file system where everyone with the right permissions can access them? Great, now you have to write your nodes defensively again, to guard against file system priviledge escalation, or just badly administrated systems... The Bus1 documentation is describing a feature, and one which is (afaik) not present in Linux right now.
> Does global ordering of messages to different services ever actually matter?
It certainly makes proofs easier, so my intuition is to say "yes". Maybe the ordering doesn't have to be globally consistent, but better safe than sorry.
Re: Bus1 is the new Kdbus
#10Judging by this description, Bus1 sounds very much like an object capability system. There is a lot of theoretical and practical evidence that this is a good programming model, and as far as I know it does not currently exist in linux. Maybe you can build a proper object capability system on top of sockets. I don't know enough about unix domain sockets to say if it is really possible to establish the right security g…
So let's assume that what you say is correct (and I have no reason to doubt it), for example, that what is required is an object capability system and that the Linux kernel doesn't adequately provide this.
Can't a generic object capability system then be devised rather than one just tied to D-Bus or systemd or whatever else will be thought of? And hopefully a system that provides local capability and easily allows distributed capability.
Because then once we have this then it could possibly be used by the likes of etcd / kubernetes or similar.