RE: [PATCH V4] binder: ipc namespace support for android binder

[chouryzhou(åå)]

> 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
> 

Since you are working on this, I will withdraw this patch. We will evaluate 
whether to your solution in our environment after you implement it.