On Thursday 16 October 2014 14:47:41 Greg Kroah-Hartman wrote: > From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > The Android binder code has been "stable" for many years now. No matter > what comes in the future, we are going to have to support this API, so > might as well move it to the "real" part of the kernel as there's no > real work that needs to be done to the existing code. > > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > --- > > This was discussed in the Android miniconf at the Plumbers conference. > If anyone has any objections to this, please let me know, otherwise I'm > queueing this up for 3.19-rc1 I'm worried about the user interface: since graduating binder out of staging with the existing ioctl interface has never been discussed as a real option and (I assume) everybody expected the way forward would be to have a replacement, I don't think it ever received the attention it should have. Specific concerns are: - I don't think there has been an audit of which subset of the API is actually required. IIRC, it was said initially that actual applications don't use all the features, and that we should have a smaller attack surface. - Using kernel pointers in user space interfaces is an information leak that can be used to construct an exploit. (I don't know if this is still used that way, I think it was doing it last time I checked). - The driver supports two versions of the user interface (v7 and v8), but only one of them can be selected at compile-time, and an 'allmodconfig' kernel will only include the deprecated one on 32-bit machines. - The implementation is not namespace-aware and will cause information to be shared across containers in a potentially harmful way. If we graduate the driver from staging, it should IMHO at least be useful in containers to run Android user space safely. Arnd _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
