All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Yao <ryao@gentoo.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: Why not make kdbus use CUSE?
Date: Tue, 02 Dec 2014 07:22:11 -0500	[thread overview]
Message-ID: <547DAEF3.1090106@gentoo.org> (raw)
In-Reply-To: <547D7159.2040900@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]

Dear Greg,

I had hoped that I could avoid reading through the code for yet another
IPC mechanism when I asked why we needed kdbus at LinuxCon Europe. In
hindsight, I should have just checked out the code and read it instead
of asking. However, what I did instead was ask and then do some thinking
based on that, mean to send an email and then sent it long after I
should have.

Our conversation now has lead me to realize my mistake and I have tried
to rectify it. I now see that kdbus is hooking into kernel interface to
implement KDBUS_ITEM_PAYLOAD_MEMFD in a way that we could only achieve
from userspace with UNIX domain sockets. I imagine that we could avoid
putting this code into the kernel through a combination of libev,
libfuse, memfds and UNIX domain sockets.

A fallback path could be provided by using anonymous files on the FUSE
filesystem. This could probably by by the sender doing something like
the following:

void *buf;
int coookie;
char *name = strdup("/sys/fs/kdbus/tmp/XXXXXX");
int fd = mkstemp(name);
unlink(name);
buf = mmap(NULL, LENGTH, PROT_WRITE, MAP_SHARED, fd, 0);
// Do your writes here
cookie = ioctl(fd, SEAL);
close(fd);
munmap(buf);
// Send a message via a UNIX domain socket to the server with the
// cookie, plus whatever XXXXXX became and instructions on where to
// send the data. If the file had been closed before the message was
// received, the server should be able to say okay. Otherwise, it can //
send an error. The server would need to have a timer to handle the
// case where a process never actually sends a message with the cookie.

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. This would preserve portability across not only
different versions of Linux, but also other POSIX systems. 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.

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. Is
there something that I have missed that make this not the case?

Yours truly,
Richard Yao


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

  reply	other threads:[~2014-12-02 12:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-29  6:34 Why not make kdbus use CUSE? Richard Yao
2014-11-29  6:34 ` Richard Yao
2014-11-29 17:59 ` Greg Kroah-Hartman
2014-11-29 17:59   ` Greg Kroah-Hartman
2014-12-02  5:40   ` Richard Yao
2014-12-02  5:40     ` Richard Yao
2014-12-02  5:48     ` Greg Kroah-Hartman
2014-12-02  5:48       ` Greg Kroah-Hartman
2014-12-02  7:59       ` Richard Yao
2014-12-02 12:22         ` Richard Yao [this message]
2014-12-02 17:26           ` Greg Kroah-Hartman
2014-12-02 17:26             ` Greg Kroah-Hartman
2014-12-03  9:22             ` Richard Yao
2014-12-03  9:22               ` Richard Yao
2014-12-03 21:15               ` Greg Kroah-Hartman
2014-12-03 21:15                 ` Greg Kroah-Hartman
2014-12-02 17:12         ` Greg Kroah-Hartman
2014-12-02 17:12           ` Greg Kroah-Hartman
2014-12-01 14:23 ` One Thousand Gnomes
2014-12-01 14:23   ` One Thousand Gnomes
2014-12-02  4:31   ` Richard Yao
2014-12-02  4:31     ` Richard Yao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=547DAEF3.1090106@gentoo.org \
    --to=ryao@gentoo.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.