On Fri, Nov 16, 2018 at 11:19:41AM -0800, Todd Kjos wrote: > On Thu, Nov 15, 2018 at 2:54 PM gregkh@xxxxxxxxxxxxxxxxxxx > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > ... > > > > A number of us have talked about this in the plumbers Android track, and > > a different proposal for how to solve this has been made that should be > > much more resiliant. So I will drop this patch from my queue and wait > > for the patches based on the discussions we had there. > > > > I think there's some notes/slides on the discussion online somewhere, > > but it hasn't been published as the conference is still happening, > > otherwise I would link to it here... > > Here is a link to the session where you can look at the slides [1]. > There was consensus that "binderfs" (slide 5) was the most promising > -- but would be behind a config option to provide backwards > compatibility for non-container use-cases. > > The etherpad notes are at [2] (look at "Dynamically Allocated Binder > Devices" section) > > Christian Brauner will be sending out more details. Ok, sorry for the delay I got caught up in other work. The idea is to implement binderfs which I'm starting to work on. binderfs will be a separate pseudo-filesystem that will be mountable per-ipc namespace. This has the advantage that the ipc namespace is attached to the superblock of the mount and can be easily retrieved by the binder driver. It also implies that - in contrast to the proposed patch here - an open() on a given binder device will not be able to change the ipc namespace of said devices. The obvious corollary is that you can bind-mount binder devices or the whole binderfs mount between different ipc namespaces and given the right permissions (CAP_IPC_OWNER in the owning userns of the ipcns) can see services on the host which is something that people wanted to be able to do. Additionally, each binderfs mount will come with a binder-control device. This device is functionally similar to loop-control and will allow for dynamic allocation (and possibly deallocation) of binder devices. With this we can remove the restriction to hard-code the number of binder devices at compile time. Backwards compatibility can either be guaranteed by hiding binderfs behind a compile flag or by special-casing the inital binderfs mount to pre-create the standard binder devices. The jury is still out on this. Christian > > -Todd > > [1] https://linuxplumbersconf.org/event/2/contributions/222/ > [2] https://etherpad.openstack.org/p/Android > > > > > thanks, > > > > greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
