Date:	Mon, 22 Jun 2015 23:31:19 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Havoc Pennington <havoc.pennington@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Daniel Mack <daniel@...que.org>
Subject: Re: kdbus: to merge or not to merge?

On Mon, Jun 22, 2015 at 11:06 PM, Andy Lutomirski <luto@...capital.net> wrote:
> 3. The sandbox model is, in my opinion, an experiment that isn't going
> to succeed.  It's a poor model: a "restricted endpoint" (i.e. a
> sandboxed kdbus client) sees a view of the world defined by a limited
> policy language implemented by the kernel.  This completely fails to
> express what I think should be common use cases.  If a sandboxed app
> is given permission to access, say,
> /org/gnome/evolution/dataserver/CalendarView/3125/12, then it knows
> that it's looking at CalendarView/3125/12 (whatever that means) and
> there's no way to hide the name.  If someone subsequently deletes that
> CalendarView and creates a new one with that name, racelessly blocking
> access to the new one for the app may be complicated.  If a sandbox
> wants to prompt the user before allowing access to some resource, it
> has a problem: the policy language doesn't seem to be able to express
> request interception.

...

>
> I'll point out that a pure userspace implementation of sandboxed dbus
> connections would be straightforward to implement today, would have
> none of these problems, and would allow arbitrarily complex policy and
> the flexibility to redesign it in the future if the initial design
> turned out to be inappropriate for the sandbox being written.  (You
> could even have two different implementations to go with two different
> sandboxes.  Let a thousand sandboxes bloom, which is easy in userspace
> but not so great in the kernel.)


I should add that I'm not just speculating about my dream sandbox
here.  Sandstorm has a very nice sandbox model that's layered on top
of an object-oriented RPC system.  Putting aside the fact that
Sandstorm would be very unlikely to use kdbus because Sandstorm is
network-transparent, the Sandstorm sandbox would not be expressible in
kdbus policy language.  Nevertheless, I suspect that the current
Sandstorm implementation (over TCP, no less) outperforms kdbus by a
large margin even though it's entirely in userspace and relies heavily
on per-sandbox userspace proxies.  If we tuned the kernel for faster
context switches (by implementing PCID, for example), Sandstorm would
get even faster.

If the kernel were to add APIs to accelerate something like Sandstorm,
the API would probably look a bit like a cross between AF_UNIX and the
seL4 API.  The kernel would not have any policy implementation
whatsoever.  D-Bus could probably be accelerated with exactly the same
API.  (Preserving the D-Bus magic power of strictly ordering
broadcasts relative to unicast messages might be tricky, but I'm not
sure that property makes sense in the underlying API in any event
except on systems that magically have infinite RAM in which to buffer
messages.  (On the other hand, all of the useful benefits of that
ordering could probably be preserved by simply explicitly tracking
event ordering in userspace.)

But no one's asking for ksandstorm because it's not necessary, and I
don't think anyone will unless someone writes a really nice, broadly
applicable accelerated kernel IPC mechanism.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists