Re: [GIT PULL] kdbus for 4.1-rc1

[Andy Lutomirski]

On Apr 29, 2015 5:48 AM, "Harald Hoyer" <harald@xxxxxxxxxx> wrote:
> Of course this can all be done, but it would involve fallback mechanisms,
> which we want to get rid off. Hopefully, you don't suggest to merge dbus with
> PID 1. Also with a daemon, you will lose the points mentioned in the cover mail
> :
>
>  * Security: The peers which communicate do not have to trust each
>    other, as the only trustworthy component in the game is the kernel
>    which adds metadata and ensures that all data passed as payload is
>    either copied or sealed, so that the receiver can parse the data
>    without having to protect against changing memory while parsing
>    buffers. Also, all the data transfer is controlled by the kernel,
>    so that LSMs can track and control what is going on, without
>    involving userspace. Because of the LSM issue, security people are
>    much happier with this model than the current scheme of having to
>    hook into dbus to mediate things.

Other security people prefer code to stay out of the kernel when possible.

Also, this metadata argument is still invalid.  Sockets can be
improved for this purpose.

>
>  * Being in the kernel closes a lot of races which can't be fixed with
>    the current userspace solutions.  For example, with kdbus, there is a
>    way a client can disconnect from a bus, but do so only if no further
>    messages present in its queue, which is crucial for implementing
>    race-free "exit-on-idle" services

This can be implemented in userspace.

Client to dbus daemon: may I exit now?
Dbus daemon to client: yes (and no more messages) or no

>
>  * Eavesdropping on the kernel level, so privileged users can hook into
>    the message stream without hacking support for that into their
>    userspace processes
>

Why would it be a hack in userspace but not a hack in the kernel?

>  * A number of smaller benefits: for example kdbus learned a way to peek
>    full messages without dequeing them, which is really useful for
>    logging metadata when handling bus-activation requests.

MSG_PEEK?

>
> I don't care, if the kdbus speedup is only marginal.
>
> In my ideal world, there is a standard IPC mechanism from the beginning to
> the end, which does not rely on any process running (except the kernel) and
> which is used by _all_ tools, be it a system daemon providing information and
> interfaces about device assembly or network setup tools or end user desktop
> processes.
>
> dbus _is_ such an easy, flexible standard IPC mechanism. Of course, you can
> invent the wheel again (NIH, "we know better") and wait and see, if that
> works out. Until then the whole common IPC problem is unresolved and Linux
> distributions are just a collection of random software with no common
> interoperability and home grown interfaces.

I don't think anyone is suggesting throwing out dbus.

>
> [1] transitioning mdmon is one of the critical parts for an IMSM raid array.
> Also running an executable from a disk, which the executable is monitoring,
> and which stops functioning, if the executable is not responding is insane.
>

That sounds like an excellent reason to just keep running the
initramfs copy, and I don't see why IPC has anything to do with where
the executable comes from.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/