Re: Why not make kdbus use CUSE?
flat view
From: Richard Yao <hidden>
Date: 2014-12-03 09:22:27
Also in:
lkml
On 12/02/2014 12:26 PM, Greg Kroah-Hartman wrote:
On Tue, Dec 02, 2014 at 07:22:11AM -0500, Richard Yao wrote:quoted
Assuming that this dance succeeds, the FUSE process could then make a readonly file in itself, open it read only, unlink it, put the data into the file and send the file descriptor via UNIX domain socket while refusing further writes. If it has its own user/group, the file should be safe from prying eyes. This is not as good as a memfd and also suffers from the race that O_TMPFILE was meant to close, but it should be able to function as a decent fallback.We can't knowingly create and advocate for broken code, sorry.quoted
This would preserve portability across not only different versions of Linux, but also other POSIX systems.I honestly do not care about any other system than Linux, so I don't see why this would ever be an issue.
If you tie your userland to the most recent kernel and then want to bisect an old bug, you will have a problem. You could try to find another userland that supports the older kernels, but it would be *much* easier if you could just use your current userland with it because then the bare minimum must change. Writing portable software is the way to do that. Why burn the bridges that allow us to look backward when we have such a need?
quoted
Keeping the code in userspace would allow us to apply SELinux policies to it, which is something that we would lose if it were go to into the kernel.On the contrary, the kdbusfs implementation gives you better security model support than before, it ties directly into the LSM hooks, see the add-on patches from some other developers that bring full support of LSM to the codebase.
If a bug in kdbusfs that allows arbitrary code execution is exploited in the wild, would kdbus be more secure than a userland version?
quoted
That said, it is still not clear to me that dbus must be inside the kernel to be able to perform multicast and zero copy using memfd.It seems you have yet to read my introductory email for the patch series.
Allow me to be more specific:
quoted hunk ↗ jump to hunk
- performance: fewer process context switches, fewer copies, fewer syscalls, larger memory chunks via memfd. This is really important for a whole class of userspace programs that are ported from other operating systems that are run on tiny ARM systems that rely on hundreds of thousands of messages passed at boot time, and at "critical" times in their user interaction loops.
What are some examples of these programs? Are any of them examples of good software design?
quoted hunk ↗ jump to hunk
- security: the peers which communicate do not have to trust each other, as the only trustworthy compoenent 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.
What keeps userspace from passing around memfds?
- more metadata can be attached to messages than in userspace
How much metadata can be attached in either case? is there some inherit aspect of the existing syscall API that prevents userspace from attaching more? Why do we want to attach more?
quoted hunk ↗ jump to hunk
- being in the kernle 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
Is the current dbus daemon not supporting this this only thing preventing us from doing it in userspace?
Of course, some of the bits above could be implemented in userspace alone, for example with more sophisticated memory management APIs, but this is usually done by losing out on the other details. For example, for many of the memory management APIs, it's hard to not require the communicating peers to fully trust each other. And we _really_ don't want peers to have to trust each other.
Does being in the kernel solve this in a way that using memfds in userspace does not?
Another benefit of having this in the kernel, rather than as a userspace daemon, is that you can now easily use the bus from the initrd, or up to the very end when the system shuts down. On current userspace D-Bus, this is not really possible, as this requires passing the bus instance around between initrd and the "real" system. Such a transition of all fds also requires keeping full state of what has already been read from the connection fds. kdbus makes this much simpler, as we can change the ownership of the bus, just by passing one fd over from one part to the other.
Why do we want to start D-Bus inside the initramfs?
Attachments
- signature.asc [application/pgp-signature] 884 bytes