Re: Why not make kdbus use CUSE?

On 12/02/2014 12:48 AM, Greg Kroah-Hartman wrote:

On Tue, Dec 02, 2014 at 12:40:09AM -0500, Richard Yao wrote:

quoted

quoted

quoted

They regard a userland compatibility shim in the systemd repostory to provide
backward compatibility for applications. Unfortunately, this is insufficient to
ensure compatibility because dependency trees have multiple levels. If cross
platform package A depends on cross platform library B, which depends on dbus,
and cross platform library B decides to switch to kdbus, then it ceases to be
cross platform and cross platform package A is now dependent on Linux kernels
with kdbus. Not only does that affect other POSIX systems, but it also affects
LTS versions of Linux.

What does LTS versions have anything to do here?  And what specific
dependancies are you worried about?

Lets say that you have a Linux 3.10 system and you want some package
that indirectly depends on the new API due to library dependencies. You
will have a problem. You could probably install an older version of the
library, but if the older version has a CVE, most end users will end up
between a rock and a hard place. This situation should merit some
consideration because you are taking something that lived previously in
userland, modifying it so that anything depending on the modifications
is no longer backward compatible and then tying it to new kernels.

Then you need to get a better distro, as any "well run" long-term
enterprise distro handles stuff like this for you.  Otherwise you need
to update systems properly.  There's nothing that I can do here to help
with that, nor do I ever want to, sorry.

Another option is to include KVM-style kernel compatibility code to
allow the module to be built against older kernels. If you target
2.6.32.y, 3.2.y, 3.4.y and 3.10.y, the risk of people on older Linux
systems being left behind would be minimized.

quoted

1. Debugging kernel code is a pain while debugging user code is
relatively easy.

You have full access to a debugger, what more do you need?  :)

I would prefer not to start bringing userland daemons into the kernel
unless there is no other choice. That way, a wider range of people can
tackle bugs and the code could be applied to a larger number of systems.

And why would you need to debug the kernel kdbus code?  Is something not
working properly in it?  Otherwise just use wireshark to read the kdbus
data stream and all should be fine.

Putting daemons in the kernel means that we further complicate already
complex relationships with regard to things like memory utilization and
CPU time. It is easier to deal with this in userland where we could
better utilize cgroups.

quoted

2. Security vulnerabilities in kernel code give complete access to
everything while security vulnerabilities in userspace code can be
limited in scope by SELinux.

Kernel code is hard, security matters, yes I know this, we all have been
doing this for a very long time.  Of course bugs happen, but if you look
closely, your "attack surface" is now smaller using kdbus than it was
using old-style dbus.

Lets say that I have a system running LXC containers, someone does full
disclosure of proof of concept code for an arbitrary code execution zero
day and then someone else tries the exploit in a LXC container on
mysystem. With old-style dbus, only the container is affected and if
selinux is used, then it is possible to restrict daemon to things in the
container using dbus. A FUSE daemon using the new protocol is similar.
However, an in-kernel version not only means that the attacker breaks
out, but he has the ability to execute code with full kernel privileges.
Every Linux container on the system is therefore compromised.

I heard quite clearly at LinuxCon Europe that there are no expected
benefits from using the shim with kdbus such that we have the equivalent
of the original dbus daemon in the kernel, but there were plenty of
benefits from the protocol. If that is the case, it seems that being in
the kernel is not a necessity, but the new protocol is. FUSE might be
somewhat slower than an in-kernel filesystem, but it allows us to
enforce least privilege like we can do now with the current dbus daemon.
We cannot do that with kdbus/kdbusfs. If the reduction in context switch
overhead actually mattered, I would understand the desire to put this
into the kernel, but I have heard quite consistently that the context
switch overhead is not a significant motivation for pushing this code
into the kernel. If it were, the current userland code could have been
adapted into a kernel module.

quoted

3. Integration with things like LXC should be easier from userspace,
where each container can have its own daemon.

How does the current implementation not work properly for this?  The
filesystem implementation makes this easier than ever, while sticking
with the character device made this quite difficult in different ways.

As you pointed out, my information was out of date. Making this into a
filesystem is an excellent idea that handles container integration quite
nicely.