Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754417AbbDTSBs (ORCPT ); Mon, 20 Apr 2015 14:01:48 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:35566 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750998AbbDTSBo (ORCPT ); Mon, 20 Apr 2015 14:01:44 -0400 Message-ID: <1429552902.2222.51.camel@HansenPartnership.com> Subject: Re: [GIT PULL] kdbus for 4.1-rc1 From: James Bottomley To: Havoc Pennington Cc: David Herrmann , Greg Kroah-Hartman , Jiri Kosina , Steven Rostedt , John Stoffel , Andy Lutomirski , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , "linux-kernel@vger.kernel.org" , Daniel Mack , Djalal Harouni , "Paul E. McKenney" Date: Mon, 20 Apr 2015 11:01:42 -0700 In-Reply-To: References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150414192357.GA6107@kroah.com> <21805.29994.968937.364993@quad.stoffel.home> <20150414215135.GC6801@home.goodmis.org> <20150415083714.GD16381@kroah.com> <1429121536.2187.44.camel@HansenPartnership.com> <1429298858.1079.22.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3488 Lines: 72 On Fri, 2015-04-17 at 16:27 -0400, Havoc Pennington wrote: > Hi, > > On Fri, Apr 17, 2015 at 3:27 PM, James Bottomley > wrote: > > > > This is why I think kdbus is a bad idea: it solidifies as a linux kernel > > API something which runs counter to granular OS virtualization (and > > something which caused Windows to fall behind Linux in the container > > space). Splitting out the acceleration problem and leaving the rest to > > user space currently looks fine because the ideas Al and Andy are > > kicking around don't cause problems with OS virtualization. > > > > I'm interested in understanding this problem (if only for my own > curiosity) but I'm not confident I understand what you're saying > correctly. > > Can I try to explain back / ask questions and see what I have right? > > I think you are saying that if an application relies on a system > service (= any other process that runs on the system bus) then to > virtualize that app by itself in a dedicated container, the system bus > and the system service need to also be in the container. So the > container ends up with a bunch of stuff in it beyond only the > application. Right / wrong / confused? Right. Consider named as the unix equivalent. In most application containers, it's provided from outside. However, any container that wants it provided inside simply intercepts and overrides the well known socket. We can do this in UNIX because there's no global bus handling these queries, it's simply a matter of knowing where the socket is. In windows you can't pick and choose the services you consume from outside. Either you pull the whole OLE namespace into the container, and thus have to provide everything from within, or try to run with none of it provided by the container. It's this everything or nothing that's the problem. Container virtualisation is about being granular and a system bus (or global OLE namespace) is about being monolithic. > I also think you're saying that userspace dbus has the same issue > (this isn't a userspace vs. kernel thing per se), the objection to > kdbus is that it makes this issue more solidified / harder to fix? Yes, it does. We have problems containerising Linux desktops as well. However, most of our server stuff is daemon and socket based, so that containerises nicely. In windows, OLE has been absorbed even into the server model which is why they have a bigger problem. > Do you have ideas on how to go about fixing it, whether in userspace > or kernel dbus? Well, I've always suspected the solution would be for dbus to have a hierarchical namespace of its own with the default policy be pass message to parent namespace. This would allow a container to determine which services were serviced outside and which inside the container (if you attach as a provider to the system bus in the container, that attachment supersedes the parent). However, this doesn't solve the security problem: just because a container hasn't attached an interior provider doesn't mean it should be allowed complete access to all services provided from outside. This is the nasty problem because it involves some type of filter on busses which pass through containers. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/