BUS1: A new Linux kernel IPC bus being made by systemd developers
phoronix.com
phoronix.com
The only other contributors are Harald Hoyer and Lars Uebernickel.
Note that Kay Sievers was a Linux kernel contributor before systemd even existed (I don't know about the other 3, perhaps they were too).
Kay, David, and Harald are all Red Hat employees, and Red Hat has mentions in the copyright statements, leading the author to suggest that this is an official Red Hat project. It could be, but it could also be that RH just owns the copyright because it's too similar to what they do at work, but it's cool because RH is fine with them open-sourcing everything. But also "notable" is that Lars is a Canonical employee, which receives no mention in the article.
My question is now: What isn't in scope for systemd?
Then again, it could swallow sslproxy by providing sockets with transparent SSL to services which don't talk SSL natively.
Systemd interacts with a many different external components. OK, that means that systemd developers are exposed to a bunch of different components, and work with them frequently. So, they find a pain-point, and they think to themselves "I could improve this." And, because they are competent developers, and it's free/open-source, they do. Sure, the reason the found a pain-point, and chose to contribute is because of their work systemd, but that contribution isn't in-scope for systemd, isn't associated with systemd. It's just them being good citizens and improving the ecosystem.
Now, remember that a significant portion of the systemd developers are also kernel developers, and have been since before systemd existed. So it's not unlikely that because of systemd, they see a way that they think the kernel could be improved. And they're contributing to the kernel anyway, so why not?
That said, many people object to the kind of design decisions made in systemd, and don't like that that those kind of decisions are spreading to the rest of the ecosystem. This isn't systemd taking over, this is the fact that certain prolific individuals, who are systemd developers, are also contributing to other projects; naturally making the same kind of decisions.
It's almost as if the programmers were experimenting with ideas that are alternatives to kdbus.
I'm appalled. What were they thinking?
Could I ask a genuine question? Aside from systemd, why do you distrust freedesktop?
At the same time, there is plenty of room for traditional sysv or bsd style Linux distributions, particularly in the cloud/container space. It boggles the mind that Ubuntu is the most popular distribution in that area, considering how many of its features are utterly unused and unnecessary on a container.
Linux could definitely use some real, simple bus interface, so why would this be bad? (assuming it won't be merged into systemd in the future)
Where's the evidence of demand for this from outside the systemd bubble, and why are all of the other existing IPC mechanisms (including those in other operating systems that could be implemented for Linux) unsuitable? The systemd devs really shouldn't be taken solely at their word that doing their favorite thing in another corner of the OS is the best decision for the broader community.
sunrpc, dcom, corba, dbus, xpcom, dci, dcop, rmi, kqueue (kind of), 9p/plumber, ...
All of them try to achieve a similar thing. Some of them can be actually used for remote calls, but a lot are used for local rpc.
They're unsuitable for the same reasons that we're using json instead of asn1, and http instead of custom interactive protocols. It's not that they don't work anymore, but because we learned how to do things better. And if bus1, or something similar could provide a low-level, common basis for more generic technologies, that would be awesome.
Regarding reuse... I don't know if any current system can provide what systemd guys want (pre-init availability and sending uid assurance)
I'm unsure of why you consider 9P to be outmoded. It certainly can be available pre-init.
Sure, 9p can be available pre-init, but it doesn't provide sender verification. (i.e. you can't map the message to local uid) It could be added to the attributes of course, but it's not standard at the moment. Is that not right?
This sounds like an attempt to implement security features the kernel already provides.
Why would you need an assurance of a UID, and why would you assume that it would stay accurate? Using UIDs to do manual security features is going to have reliability issues, and if it's for a non-security feature, you don't need an assurance.
This impacts issues like configuring wireless networks without being an admin. (which is what most people want in practice)
The reason you leave these things to the kernel is the kernel is the only place that can actually make the proper security determination.
A file-permission analogy: it is a bad idea to stat(2) a file to probe if it's possible to open it. The kernel already provides that capability, which you have to handle anyway. The proper design is to open the file, and handle the EACCES error. Testing first doesn't work because the situation can change between the stat(2) and the open(2).
> configuring wireless networks
There are many ways to handle that, which do not require abusing UIDs for security features they weren't designed for.
edit:
No, I absolutely am not agreeing with you. Using UIDs for security outside the kernel (which is where the assurances your new kernel feature would provide will end up) is fundamentally broken. It works inside the kernel because the kernel can lock whatever is necessary.
You are only moving the race condition. You ask your new interface for the sender's UID, an interrupt happens, and the data you got may no longer be valid as the sender called setuid().
The way it's been proposed in kdbus is not by querying. Messages simply get the additional information attached to them so it's guaranteed to be correct at the time of sending.
why not tipc ? it is already there in the kernel, and seemingly well tested at that. why re-invent the wheel ?
I'm not criticizing btw, just asking out of curiosity.
[1] http://www.golem.de/news/systemd-und-launchd-freebsd-gruende...
And the Gentoo devs are big fans of systemd, so while technically you can use it without, given how many tendrils systemd has got into things I think the amount of work it'll be to maintain the USE="-systemd" flag is going to mean it's a second-class citizen. Slackware will keep chugging along, though, as always.
> Slackware will keep chugging along, though, as always.
Indeed, they were more or less silent on the whole systemd issue for a while but Eric Hameleers recently mentioned dropping udev in favor of Gentoo's eudev specifically because of what he calls "standards-violating systemd crap"[1] in udev, which means Slackware will be a safe haven for at least the next major version or so.
I think it's really down to whether the people driving the project are your kind of people. That's what pushed me away from using Linux after using it 14 years, and what made FreeBSD so great to arrive at. People making similar decisions to what I would make in the same scenario - it makes using the OS like putting on a well-fitting glove (after a few initial bumps as you sort out which Linuxism don't work well on BSD, of course).
RH's lack of having their hands in everything (only kinda kidding)
My interpretation would be: universal, global interfaces for all system things. Which is not a bad goal in itself.
It's worse than a bad goal. "Universal, global interfaces for all system things" is a goal that is cognitively meaningless.
Dbus is an abstraction that allows actions with rich information and context, and makes it possible to define simple interfaces to potentially complex sets of actions. Systemd and related services fulfill those interfaces.
Why do you think that's a bad goal?
The second paragraph is more wind.
I don't think it's a bad goal. You haven't even specified a goal.
As for syscalls - they can carry a lot of data. That doesn't make it rich, structured information. Sure, everything is just writing/reading bytes at the end of the day. But there's a reason we've got open() function and don't use syscalls directly - rich interfaces are nice. Syscalls are definitely low level (they're defined in the cpu specs, how much more low-level can you get?).
Even your list involves diverse interfaces ranging from real-time kernel primitives to end-user archives (packages), so again, "system things" is more of a justification for perpetual consumption than anything resembling a mission statement or goal.
(Things that merely wrap syscalls would probably be part of a utilities package anyway, a la util-linux.)
I can agree systemd situation is bad, but I don't think it's because of technical reasons. Leaving systemd out of it, what's bad about the idea that distributions, backend services, and client applications start using a common bus that has an interface for action "The system timezone is now XXX"? (and similar actions for network configuration, printers, sessions, and "all everything things")
It is: http://blog.darknedgy.net/technology/2015/10/11/0/
The context of this comment section was about systemd in general, not the BUS1 concept specifically. It's too early to comment on the latter when it's still just a red-black tree with some stub functions.
For example, systemd doesn't need to provide an http daemon, because it's not helpful to other services to provide that functionality. There's httpd already. But systemd does naturally provide some date and time functions. That's because the system log functionality needs to throw time stamps on everything, and starting processes at regular intervals also relies on knowing the system time, so it naturally fits in as part of what a process management daemon should provide.
"Rethinking PID 1" from 2010
http://0pointer.de/blog/projects/systemd.html
Some quick LKML searching etc brings up bus1 references in relation to ARM and devicetree.
* ... "Kay Sievers is writing a replacement for udev named /usr/bin/org.bus1.devices."
* ... "Kay Sievers is writing a replacement for Dracut init named /usr/bin/org.bus1.rdinit."
* ... "Kay Sievers is writing a replacement for gummiboot that hardcodes support for Microsoft's Boot Manager for Windows." (https://github.com/bus1/boot-efi/blob/c7f3a8a25acc838677b08d...)
* ... "David Herrmann is writing a replacement for kdbus named bus1."
* ... "Kay Sievers is writing a replacement for systemd named /usr/bin/org.bus1.init."
* ... "Lennart Poettering made no comment when asked about Herrmann's bus1 and kmscon, systemd-consoled having been quietly pulled from systemd in July 2015." (https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...)
The simple fact is that it is an IPC mechanism, and it almost certainly indeed is an attempt to come up with a replacement for kdbus, given the latter's withdrawal a while back. It was Herrmann himself who pulled systemd-consoled, and he did so citing the fact that he was working on kdbus. (https://github.com/systemd/systemd/pull/747) It's not shocking to find him working on a successor. The mechanism is currently a filesystem like devpts, containing a pseudo-file named 'bus' that client applications open and perform ioctl()s on. The caveat "currently" is because there's no design documentation there, and the thing is far from finished. There's no guarantee that that will be its final form.
The replacement plug-and-play manager, EFI boot loader, and process #1 programs look like the majority of the project because the test infrastructure for using the new bus, essentially a very feature limited bootstrap system, has been written more quickly than the actual kernel IPC subsystem itself has been.
It's fair to say that this is at roughly the same stage of development as SystemXVI is, albeit that SystemXVI does have design doco (https://github.com/ServiceManager/ServiceManager/blob/master...).