Re: Why not make kdbus use CUSE?

[Richard Yao]

On 12/02/2014 12:26 PM, Greg Kroah-Hartman wrote:
> On Tue, Dec 02, 2014 at 07:22:11AM -0500, Richard Yao wrote:
>> 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.
>
>> 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?

>> 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?

>> 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:

> - 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?

> - 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?

> - 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?

Attachment: signature.asc
Description: OpenPGP digital signature