On Tue, Dec 02, 2014 at 02:59:21AM -0500, Richard Yao wrote: > On 12/02/2014 12:48 AM, Greg Kroah-Hartman wrote: > > On Tue, Dec 02, 2014 at 12:40:09AM -0500, Richard Yao wrote: > >>>> 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. If you want to do that for an out-of-tree patch/module, feel free to do so, but this has nothing to do with the in-kernel kdbusfs code, sorry. > >> 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. What exactly do you mean here? There are thousands of people who know how to properly debug Linux kernel code, this isn't an issue at all. > > 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. What does cgroups have to do with dbus userspace libraries here? In fact, I don't think you looked at the code, as we properly tie into namespaces and all the stuff you can only do in the kernel, you aren't reading my introductory email at all that explains all of this. > >> 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. And how exactly does this relate to the kdbusfs code? Please, stop making random statements that have nothing to do with the code being proposed. > 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. You heard wrong, the context switch removal is a big thing, and a major issue for a lot of users. But that's not the only reason this is being proposed, again, go read and respond to the 00 patch introduction please, or even better yet, read the code and documentation and respond to issues you find there. Again, FUSE makes no sense here, sorry. > >> 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. I'm glad you agree with the current implementation, thanks for your approval. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
