Linus Is Looking Forward To Merging KDBUS, But Not Convinced By Performance

[gens]

dbus is the protocol for sending/receiving data, you're talking about specific interfaces, where as if everyone invents their own alternative to sending data via sockets you're bound to end up with a bunch of incompatible solutions using different protocols.



I mean that it is then up to each application to handle the security of its IPC, instead of relying on something that is designed exactly for that purpose. The same exact problem as above.

what do you mean by "if everyone invents their own alternative to sending data via sockets"
on linux you have only sockets (a few types), named/normal pipes and shm (few ways to obtain)

the msg transport layer does not matter if all you do is send/receive msgs to clients
with UDS you can even broadcast a msg

UDS even lets you find out the PID of the sending process, from it you can find out anything about it


do give me an example of a security flaw of just sending data over UDS
it cant be sniffed, it cant be faked, idk what you can do to compromise it

maybe you are thinking of sending data that makes the program like, idk, copy msg contents to an arbitrary address in memory ?
i imagine that only happening with a shm protocol, if the msg parser is really broken (like, idk, telling it the data length is 10MB)

if the program tilts on a invalid msg it will tilt on an invalid msg
that will happen if the msg was sent over UDP, TCP, UDS, dbus, fifo, whatever
there is nothing specific to something like UDS that would make it any more or less vulnerable

thx for inciting me to validate my statements
it made me find this handy overview of UDS


EDIT:

that reminds me that UDS needs a file somewhere
and a filesystem is a namespace (despite what many seem to think)
so to discover a "service" one would only need to check if the file is there

[duby229]

Ok, we'll switch to using sockets. Great. Now every application and it's dog has a slightly different protocol, and it's nearly impossible to interconnect things that were not designed specifically to interconnect. And throw security out the window too, because now every damn application handles that differently.

Or we could just use kdbus, which is now more capable of handling large amounts of data than dbus ever was.

Oh I seriously can't wait for that. I'm gonna be able to say "I told you so" so hard!

As soon as dumbasses start throwing large data onto dbus, Oh the fuel I'll have against those fools.

[interested]

http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol

the protocols first byte is an endianness flag
-it deals with endianness, that no sane protocol should

Endianess is a real problem when making a standard that works across multiple platforms and architectures like D-Bus does. What wasn't obvious at the time 10 years ago, was that you should just turn on one of the standards like "little" and let the "big" architectures performs an endianess swapping in their own implementation of the reference standard. In any case, this is just a minor cosmetic detail and doesn't make the protocol complex to neither understand nor use.

-the "flag" is one byte, instead of 1 bit
2nd byte is msg type, theres 3 (plus error and "unknown")
3rd byte is an OR of 3 flags
4th is the protocol version (mind you this goes in every msg)
then there are 2 32bit paramaters, data length and a cookie
and still no data, data comes after additional paramater fields that depend on msg type and flags

that's just a basic msg format, the protocol defines a lot more things
maybe you are thinking about the API

Really, the D-Bus protocol isn't hairy or complex. It isn't simple either, but neither is the problem it solves.

and no, i never said you should reinvent broadcasting
i specifically said that dbus should not be used for latency or throughput sensitive problems
for example; using dbus to discover/connect to a media player is fine, while using dbus to actually transport the media is not

The point is exactly that D-Bus as it is now doesn't work well with large data transfers. That is one major reason both desktop and daemon developers wants kdbus, since running the D-Bus protocol on top of the kdbus shared bus makes such data intensive transfers both fast _and_ secure.

And yes, you really want to use all the communication and security framework features that kdbus/D-Bus provides for the data too.


The bottom line is, that if you want to solve the same problems as kdbus/D-Bus does, you will end up reinventing both, the difference being that this alternative solution would have zero deployment in user space, unlike D-Bus that is widely supported in both daemons, desktops and init systems. You would basically have to re-write the world instead of re-using what is at hand. An insane trade-off.

Sure, you could let D-Bus run atop of a more generic kernel IPC than kdbus. But such a generic IPC for Linux have been a pipe dream for 25 years. As it is now, nobody even have any serious plans for such a generic IPC, nor the funding, nor the backing from user land.

[duby229]

The large data argument has already been debunked. Torvalds said plainly, if it was just for that, then there's no chance it would get merged. Shitty userspace code is not a reason to put junk in the kernel. Besides as soon as dumbasses start putting data on it, it's gonna backfire hard right into their faces.

[interested]

The large data argument has already been debunked. Torvalds said plainly, if it was just for that, then there's no chance it would get merged. Shitty userspace code is not a reason to put junk in the kernel. Besides as soon as dumbasses start putting data on it, it's gonna backfire hard right into their faces.

No he didn't. It really pays well to read closely what Linus says, since he often is quite precise if indirect in his communication. What Linus said was that on the basis of what he had seen _yet_, he wasn't convinced about the speed argument.

This is Linus's way of saying the kdbus should deliver some real world benchmark examples. So if the kdbus developers are smart, they will do so. They have already made a improved D-Bus library (sd-bus) they can use for the test too.

PS. those "dumbasses" are Linux open source kernel developers, working for the Linux foundation or Linux distros. What exactly are your credentials for calling them names? If you think name calling is a substitute for technical arguments, then you are wrong.

[gens]

No he didn't. It really pays well to read closely what Linus says, since he often is quite precise if indirect in his communication. What Linus said was that on the basis of what he had seen _yet_, he wasn't convinced about the speed argument.

This is Linus's way of saying the kdbus should deliver some real world benchmark examples. So if the kdbus developers are smart, they will do so. They have already made a improved D-Bus library (sd-bus) they can use for the test too.

PS. those "dumbasses" are Linux open source kernel developers, working for the Linux foundation or Linux distros. What exactly are your credentials for calling them names? If you think name calling is a substitute for technical arguments, then you are wrong.

they do not work for the linux foundation
and Linus did benchmark the thing, properly
unlike the devs that claim it brings 1000x speedup, that didn't benchmark it properly
actually the only other benchmark was by a person not even closely related to any of this

compared to something like the latest scheduler, that has a scientific paper with micro and real world benchmarks
it showed and explained where the new scheduler will be better and worse then the mainline one, objectively with numbers

if the kdbus devs were smart they would note that the overhead of dbus as used today is not even above margin of error
and they would have left it alone
maybe improved the server part and especially the glib part


and no, dbus is complicated
that what i showed is just a client sending a msg to a server
the server does a lot more
its 13k lines of code, for gods sake

[Ansla]

Endianess is a real problem when making a standard that works across multiple platforms and architectures like D-Bus does. What wasn't obvious at the time 10 years ago, was that you should just turn on one of the standards like "little" and let the "big" architectures performs an endianess swapping in their own implementation of the reference standard. In any case, this is just a minor cosmetic detail and doesn't make the protocol complex to neither understand nor use.

Endianness is a problem INSIDE a single machine? The only time you need to care about endianness is when you send data to/receive from a different machine that might have a different native endianness.

You may say that whoever designed that piece of crap was a visionary and thought of a time when the dbus protocol might be used to communicate between different machines, but then it's a lot more efficient to decide at compile time that you need to convert to big endian (x86 has the XCHG and BSWAP instructions exactly for this) instead of branching at run time over the first byte you received in the message.

So face it, the presence of that byte is a testament to the ignorance of the author on that endianness is and how it should be dealt with.

[TheBlackCat]

Endianness is a problem INSIDE a single machine? The only time you need to care about endianness is when you send data to/receive from a different machine that might have a different native endianness.

You may say that whoever designed that piece of crap was a visionary and thought of a time when the dbus protocol might be used to communicate between different machines, but then it's a lot more efficient to decide at compile time that you need to convert to big endian (x86 has the XCHG and BSWAP instructions exactly for this) instead of branching at run time over the first byte you received in the message.

So face it, the presence of that byte is a testament to the ignorance of the author on that endianness is and how it should be dealt with.

On a given machine, not all data has the same endianness. For example, all network data is big-endian, no matter what the native platform is. And some architectures natively support arbitrary endianness in a given piece of data.

So yeah, on x86, using local data, it doesn't matter. But on arm it matters no matter what, and even on x86 it matters if moving data from the network around.

[gens]

Endianness is a problem INSIDE a single machine?

endianness is not even a problem with networks
the protocol should just state if it's big or little endian in the definition and the machine can byte-swap itself if it needs

only place where its useful to define in a protocol is if the protocol will be used either between big endian or little endian machines, without much mixing
then again if the machine is running over... idk 10MHz then the overhead of byte swapping is negligible

none of this applies to dbus

PS i hate utf8 BOM

[stoatwblr]

Great.... now would he mind kicking nfsd out of the kernel and back into userspace where it belongs?