Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753522AbbFWGbs (ORCPT ); Tue, 23 Jun 2015 02:31:48 -0400 Received: from mail-la0-f43.google.com ([209.85.215.43]:36229 "EHLO mail-la0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751483AbbFWGbk (ORCPT ); Tue, 23 Jun 2015 02:31:40 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Mon, 22 Jun 2015 23:31:19 -0700 Message-ID: Subject: Re: kdbus: to merge or not to merge? To: Linus Torvalds , "linux-kernel@vger.kernel.org" , David Herrmann , Djalal Harouni , Greg KH , Havoc Pennington , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Daniel Mack Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3259 Lines: 61 On Mon, Jun 22, 2015 at 11:06 PM, Andy Lutomirski 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/