Java OpenBinder Extension

Radu-Corneliu Marin Daniel Urda Nicolae-Vladimir Bozdog School of Computer Science and School of Computer Science and School of Computer Science and Automatic Control Automatic Control Automatic Control Politehnica University Politehnica University Politehnica University Bucharest, Romania Bucharest, Romania Bucharest, Romania Email: [email protected] Email: [email protected] Email: [email protected]

Abstract—Although Java is renowned for its myriad feature a Java techonology, is easily integrated into basic Java code, set, we found that it lacks in performant Inter-Process Commu- but because it was designed and implemented for transparent nication. A somewhat recent development in said domain, the remote calls on machines over a network, it has a consistent OpenBinder C/C++ framework, has introduced a novel inter- process communication abstraction which we believe could be overhead in dealing with an IPC call. easily extended into Java by using the Java Native Interface. In our paper, we present a novel inter-process communica- In our paper, we introduce JOBe, namely the Java OpenBinder tion method based on a native C++ solution, namely Open- extension. Such an endeavor has been attempted a few years Binder. The basic difference between this solution and the back, when the Google team that developed Android designed previously mentioned solutions, is that OpenBinder is strictly and implemented the core of the aforementioned software stack: the Binder framework. Based on their concepts, we are extending oriented for IPC, as opposed to the latter. Instead of using the OpenBinder framework into Java as to offer extremly flexible sockets for correspondence between processes, OpenBinder Remote Method Invocation, based on the Binder abstraction. has introduced a unique method: passing a method call to a Linux kernel module, which, in turn, reifies the identity I.INTRODUCTION of the caller and of the callee and forwards the call to the As Java is growing in popularity, its flaws are becoming remote process (and in fact returns the result back to the more apparent each day. One of the most pressing limitations, caller). Therefore, porting such a solution into Java is not it being the one we are interested in, is the lack of performant compatible with most operating systems, other than some IPC - inter-process communication - methods. Linux distributions. This issue is of no concern for us, as A rudimentary technique in Java for communication be- OpenBinder can be ported onto other platforms as well, while tween processes (and even for programs written in different the Java interfaces remain untouched. programming languages) is using a protocol over sockets in Our paper is structured as following: Section 2 presents order to broker correspondence between two ore more entities the background for our work, most importantly it describes running in the same process or in other processes, on the OpenBinder and Android’s Java extension for it. In Section 3, same machine or on remote machines. Such a method is we present the design and architecture of our solution, whilst cumbersome to use, it implies a huge amount of effort to Section 4 entails its implementation and issue coverage. We design, to implement, to maintain and to debug secure inter- end our work with our observations, conclusions and plans for process communication. We consider such a method as being forthcomming features in Section 5, respectively Section 6. obsolete and do not consider it to be valid. For years now, many frameworks and standards have been II.RELATED WORK developed for RPC - remote process calls - or for distributed Although OpenBinder introduces numerous interesting con- objects, such as XML-RPC, respectively CORBA, and most of cepts, it has not yet been popularized or documented. This them have received praise, though none managed to become is mostly due to the fact that the OpenBinder project was a de facto standard in said domain. Although, not one of abandoned about the time that Android’s Binder was being these solutions were designed with respect to inter-process designed and implemented. Therefore, we feel obliged to communication, they represent valid choices in this direction. render a detailed description of the inner-workings of Open- Because these solutions present penalties, usually represented Binder and to provide an overview of Android’s view over by large time to execute the IPC call, we are not interested in the Binder mechanism. This second section is dedicated to them. the aforementioned subjects. Probably one of the most notable solutions for IPC in Java is RMI - Remote Method Invocation - which ”enables the A. OpenBinder programmer to create distributed Java technology-based to Dianne Hackborn, former manager of the OpenBinder Java technology-based applications, in which the methods of project and famous engineer at BeOS, PalmOS and currently remote Java objects can be invoked from other Java virtual Google, described OpenBinder as ”a new approach to operat- machines*, possibly on different hosts” [4]. RMI, being itself ing system design, in the same vein as a lot of other attempts at introducing a modern object oriented approach to operating threads awaiting Binder operations. system design” [2]. 4) BINDER SET REPLY TIMEOUT - sets timeout for The OpenBinder introduces an interesting abstraction, awaiting replies for Binder commands. namely the Binder, which is used to design and implement 5) BINDER SET MAX THREADS - set the number of a distributed component architecture by means of abstract threads in the thread pool. interfaces, their behaviour and their implementation: ”As long A Binder IPC operation is also called a Transaction. as you are using these interfaces, the actual object behind them Last, but not least, the kernel module has another key can be written in any language with Binder bindings, and exist responsability in the communication mechanism: it performs anywhere your own address space, in another process, or even mapping of objects from one process to another. An object (eventually) on another machine” [3]. reference has two mutually exclusive forms: an address - In broad strokes, OpenBinder is similar to CORBA on local references - and a handle - remote references. The local Unix, but unlike most distributed component architectures, the process sees a Binder reference as an address in its own Binder is ”system oriented rather than application oriented” address space, but when initiating a Transaction it sends a [3], in other words it is designed to support system-level com- 32bit handle to that reference, which the remote process sees ponents having its focus not on cross-network communication, as a point to the object in its local address space. The module but on inter-process communication. performs the translation between pointers and handlers, being The core of the framework is the smooved executable which the sole mapping manager. is the main Binder server. Its main purpose is to set up the That having been said, if the Binder module is inserted Binder environment by creating a Root Binder Context by into the kernel, the smooved executable has the responsability dint of which components (such as services) will be made of becoming the global host of the root namespace created available. The smooved executable is also responsible for start- by the kernel module, in other words smooved assumes the ing the Package Manager, which will host the components, role of host of the root SContext namespace. Each Binder and for starting the Process Manager, which will run the is passed in a reference of Context representing the link to components in. the OpenBinder environment. For situations in which Binders The Binder abstraction alone is used only for intra-process are not present, references to Context can be obtained from communication and, in order to take advantage of the multi- the smooved process by means of the SContext class as process bindings, the OpenBinder kernel module needs to be following: built and inserted into the kernel. The module’s main purpose SContext SystemContext() is to create and manage a thread pool which takes care of 1) the inter-process bindings, also called a root namespace. It is This method is a back-door to obtaining the root or sys- designed as a character device placed in /dev/binder and it tem context. Although it is initially created by smooved is interfaced by means of ioctl calls. The Binder module is with full permissions, access to it is restricted and may responsible for reifying the identity of the calling process and not return a valid context. SContext UserContext() the identity of the callee process. It marshals the parameters 2) sent for the remote method invocation and the results returned This method is a back-door to obtaining the global user after execution through the kernel from the host process to context. This returns the least-trusted context which is the remote process and back. The custom kernel module always guaranteed to exist, but the functionality offered is used instead of standard Linux IPC facilities in order by it is fairly limited. to model IPC operations as thread migration. Although this OpenBinder also offers a Support Kit consisting of a suite component is optional (all other OpenBinder features will of classes and utilities which ease the development of Binders. function properly without it), it is the backbone of the inter- The most significant components are the following: process communication solution. 1) SValue The reification process in the kernel module is done by The SValue is a generic container for a blob of bytes that means of file descriptors: if a user-space thread participates has a type code associated with it. Its most significant in Binder IPC, it has to open the /dev/binder and the file feature is its genericity: it can contain complex data descriptor obtained is used to identity the initiator and recipient structures or simple typed data. of Binder IPCs. The IPC mechanism makes use of the file 2) SParcel descriptor in order to interface with the driver through a small The SParcel is a container of raw block data and it is set of ioctl commands: used to marshall SValues for inter-process communica- 1) BINDER WRITE READ - used for dispatching tion. Binder commands after which blocks to receive in- 3) SAtom coming operations and related results. This is the key The SAtom is a base class for reference counted objects. command for all Binder IPC. By definition, Binder objects are reference counted (in 2) BINDER SET WAKEUP TIME - schedules a user- order for the kernel module to take them into consid- space event at a given time. eration). Classes should either inherit from it and all 3) BINDER SET IDLE TIMEOUT - sets timeout for pointers to an SAtom must use a sptr and wptr smart pointer template classes instead of raw pointers. Android has also extended the functionality offered by OpenBinder uses IDL - Interface Definition Language - to OpenBinder with the following features: ease generating Binder interfaces. The framework provides the • File descriptors may be passed between processes, pidgen tool which parses IDL interfaces and generates neces- • Memory (heap regions) may be shared between pro- sary code for Binder transactions. IDL interfaces may import cesses, other interfaces and can define functions - Binder methods, • Binders may be transacted between processes. events - methods called on specific events - and properties A more accurate overview of the Android Binder Java - Binder state values. The pidgen tool mainly generates two extension can be seen in Figure 1. As can be observed the Java classes both of which implement the defined interface and that layer sits on top, mapping the Java IBinder onto the native one. derive from the BBinder class - the standard implementation The Java Binder is mapped onto the native Binder by means of the core Binder interface, namely the IBinder: of helper classes such as JavaBBinderHolder and JavaBBinder 1) a Binder class - the class which will implement the which are responsible for converting the instances between interface and which will be registered in the Package Java and C++. Manager by means of the Binder root SContext. 2) a BinderProxy class - the class which provides a schele- ton for remote accessing the Binder class instances. It provides stubs for all the methods in the interface; each stub marshalls its parameters, initiates a Binder Transaction, waits for results and returns them in a transparent fashion. The only issue that OpenBinder raises is its old age. Due to the fact that the project was abandoned in 2005, it has become deprecated: the main problem is in the kernel module that has been developed for the 2.6.10 Linux kernel and porting it to the latest Linux kernel is a complicated task and not part of the current article.

B. Android Binder Considering that ”the Binder could be described as a <>. It doesn’t do anything itself, but is an enabling tool for implementing other rich frame- works, such as the view hierarchy, media framework, etc” [3], Fig. 1. An Overview of the Java binder implementation [1] Android has taken it literally and has built all the System Servers based on the Binder framework. In order for this The core of the Android Binder framework is the IBinder solution to be feasible, they have enriched the OpenBinder interface which is implemented by all Binder components, kernel module and have ported it to a newer Linux kernel NativeBinders and BinderProxies alike. The IBinder defines version, namely 2.6.35. a crucial method, namely transact() which, on the client The novelty of their solution is that they did not just bring side marshalls the data and method code to the Binder kernel the OpenBinder framework up to date, but they have also module and waits for results, and on the server side it invokes extended the native C++ implementation into Java as well. By a Java callback onTransact(), marshalls the results and sends so doing, they were able to create a safe, fast and dependable them back to the kernel module. Marshalling is performed Java based software stack based on the Binder IPC Model. by means of the Parcel class which serializes primitive types Although the Android Binder infrastructure is based on such as int or float, but also live IBinder objects and serialized the original OpenBinder implementation, there are also dif- Parcelable objects. ferences: We consider the Android implementation as our base state- of-the-art reference and its influences are noticeable in the • The smooved server is no longer used. Instead Android defines the ServiceManager Java class (which also has following sections, namely Architecture and Implementation. native C++ hooks as well), which is responsible for regis- III.ARCHITECTURE tering all Binders for System Services such as the Sensor Manager, the Battery Manager, the Activity Manager and The third section describes the JOBe proposed architecture many more. which contains elements from both OpenBinder and the An- • Android has abandoned the pidgen tool. Instead it pro- droid Binder, but also components introduced by us. vides the aidl tool which no longer offers support for Figure 2 illustrates the JOBe architecture. The following native C++ IDL files, but for Java IDL interfaces (which components are directly visible or indirectly deductible from are modelled like standard Java interfaces). datapaths: transaction by means of the JOBService and wait for results or Exceptions. • Remote Object: will be further referenced as Binder. This component actually offers the true implementation of the interface. It (probably) lives in a separate pro- cess and is accessed by means of the JOBService. It unmarshalls the arguments, executes the methods body and marshalls return values or Exceptions back to the Binder Proxy through the JOBService. • Parcel: means of marshalling data. All Binder methods pass arguments and returned values through serialized data containers, namely Parcels. A Parcel contains raw data with associated datatype. The Parcel class has equiv- alents both in Java and C++ and a sound mapping between the two leads to more feasible marshalling and unmarshalling. Fig. 2. JOBe architecture As can be observed from the detailed architecture, the Android Binder has left its mark on our solution due to the fact that we could not ignore our predecessors in this direction. • OpenBinder core: in order to be easily compatible with Although, the Android solution is complete and sufficient Linux distributions, we have preserved the OpenBinder we believe that our changes infer different, but valuable, smooved server and kernel module. These components semantic information: we have chose not to add the IBinder offer the means to register/lookup binder services (instead Java interface, which in Android was implemented by Binders of implementing yet another server which has to be set and Binder Proxies alike to show the relationship between the up) and also provide the functionality that allow kernel two components, even if they both implemented the cross- Binder calls. The Binder is continuosly running in the process interface as well. We believe that in a semantic Linux system, in order to ensure the availability of the sense our solution separates the Binder abstractions from the inter-process communication mechanisms. interface itself, as to illustrate a more transparent system to • JOBService: it is not visible in the Figure 2, but the the programmer. In order to reflect this, we differentiate the green datapath offers insight into its functionality. It is local and remote object by separate components the Binder and an OpenBinder native service which actually represents the Binder Proxy in which the only common point between the communication media by means of which Java Binder them is the cross-process interface they are implementing. This calls will run upon. The simplicity of this service is given solution is also complete and sufficient for our needs, because, by our solution in which the native service does not need as opposed to Android, we do not plan on sending Binder to know about the actual Java method it is executing, it objects by means of Binder IPC calls. only acts as the communication channel by which Java The true transparency provided by our framework is illus- messages are passed from process to process, from virtual trated in Figure 2 as the blue datapath. From the programmer’s machine to virtual machine. point of view, all the aforementioned components are not • an interface between the Local and Remote objects visible because the Binder inter-process method invocation represented by means of the blue datapath. This is an appears to act as regular Java method invocation. The only implicit component describing the agreement between apparent difference is that Binder method invocations must local and remote objects. Java interfaces need to be parsed treat the case of remote exceptions. by an automatic tool which offers a formalization for Java method calls. In this sense, our framework extends IV. IMPLEMENTATION the definition of a regular Java method invocation, that This section covers the actual implementation of the ar- of being a standardized method to send a message to an chitecture presented in the previous section. In designing and Object. Each method is standardized as a tuple , where Code is a unique C++ programming languages, the OpenBinder framework and, code identifying the method in the interface, Arguments in order to create the links between them, we have used the being a container describing the argument data with their Java Native Interface. In the following subsections, we have associated datatypes and ReturnType being the datatype covered all of our tools and components in detail. associated with the method result. • Local Object: will be further referenced as Binder Proxy. A. JOBService This component represents the local connection to the As mentioned in the previous section, the JOBService is a remote object. It contains stub implementations of the simple OpenBinder component which is responsible for acting interface which marshall arguments, initiate a Binder as the communication media by which Java callbacks are passed between processes. In implementing said component initialize(); we have used the IDL description language provided by OpenBinder. The interface is depicted below: static { interface IJobService { initialize(); methods: } void onTransact( SParcel in, The native initializer is used to create a BnJOBService SParcel *out, instance, pass it a reference to the onTransact abstract method int methodCode); and the yet unknown interface name (represented by the ab- stract getInterfaceName method). The class initializing is done } in a static context, as to guarantee that when the implementing The purpose of this interface is to define an OpenBinder class is loaded, the BnJOBService tied to it is registered once service which serializes arguments through the in SParcel and only once to the smooved server. and return values through the out SParcel, and passes both An outstanding issue that occured in the implementation alongside the unique methodCode to identify the Java call- of this component is its registration to the smooved server. back that needs to execute. Using the pidgen tool, we have As mentioned in the second section, in order for a service obtained the BnJOBService and BpJOBService, representing to be taken into account by the OpenBinder framework it the native Binder, respectively the native BinderProxy. The needs to obtain an external SContext instance. Although, the BnJOBService is responsible for mapping the in SParcel to OpenBinder implementation offers two Binder contexts: user a Java Parcel and passing it along with the methodCode to a and system, neither of them is able to register our component Java callback registered when creating an instance of the native into the system - the user context does not have enough Binder; also the Binder waits for the Java code to execute, privileges and the system context returned by the framework marshalls the results into an SParcel and ends the Binder is not valid. The solution to this problem is to re-implement call. The BpJOBService is the mirrored component, which the Package Manager included in the smooved server and such actually maps the arguments Parcel into an SParcel, initiates an endeavor is not included in the current paper. an OpenBinder transaction sending the arguments alongside the methodCode and waits for the transaction to return the C. Binder Proxy values, which are marshalled and sent back into the Java code. The Java Binder Proxy is also an abstract class which maps This component is built only once, and used by all Java onto the BpJOBService. It’s implementiation is presented Binder classes. In this sense, we have introduced a naming below: scheme in order for the smooved server to distinguish between abstract class BinderProxy { different components: the Java interface name and package are passed into the BnJOBService and BpJOBService and their private native void concatenation is used to register or lookup the component in the OpenBinder framework. transact( Parcel in, Parcel out, B. Binder The Java Binder is defined as an abstract class which maps int methodCode); onto the BnJOBService. It is declared as following:

abstract class Binder { public abstract String public abstract void getInterfaceName(); onTransact( Parcel in, } Parcel out, In comparison with the Binder class, the BinderProxy is int methodCode); much simpler: it also complies to the naming scheme, fact reflected by the abstract getInterfaceName() method and what it actually does is forward all calls to the native transact() public abstract String method. In C++ code, this looks up the service on the smooved server and initiates a Binder transaction passing in getInterfaceName(); the arguments passed from Java code. As mentioned in the Binder implementation, the Binder- Proxy is also affected by the SContext issue as it cannot lookup private native void a service that could not be registered to OpenBinder. D. Parcel and Parcelable • generate the BinderProxy class. This is no longer an The Parcel concept is borrowed from the Android solution. abstract class as it provides stub implementations for It is a container for raw data and it also contains datatypes all methods. For each method, it uses the marshalling associated with the data within. Our Parcel class is currently code generated above to serialize the arguments and calls implemented using a Java Vector which retains data and type into the native C++ code in order for the BpJOBService as well. We provide methods for marshalling and unmar- to initiate the Binder transaction with the appropriate shalling primitive types. In order for Objects to be passed component. The results returned by the Binder transaction between virtual machines we have implemented the Parcelable are passed back into the Java onTransact() callback. interface, also borrowed from the Android Binder. It’s purpose After the code generation is finalized, the programmer only is to force serialization: needs to implement the Binder’s code for the cross-process interface. public interface Parcelable { As can be seen and how we actually mentioned in the Parcel toParcel(); ”Architecture” section, the entire development process is trans- parent to the programmer as he or she is oblivious of the inner } workings of our framework.

Our Parcel model maps upon the SParcel class defined by V. EXPERIMENTAL RESULTS the OpenBinder SParcel datatype which may be passed in The most significant outcome of our project was building native Binder transactions. Currently our mapping is probably and running the OpenBinder framework. Due to the fact not the best, because conversion between the Java objects and that the project was abandoned more than 7 years ago, the the C++ instances cannot be automatized. This creates an issue build process was tedious and cumbersome and required most for the JIDL tool presented in the following subsection. A specific features: the 2.6.10 kernel and headers, gcc 3.4.0, possible fix for this problem could imply passing the address of bison 1.875d, flex 2.5.31 and Java 1.5. This prooved to be a SParcel pointer to the Java instance as well. By so doing, all the winning configuration that permitted us not only to build operations would operate directly onto it and conversion would OpenBinder but also applications based on the aforementioned be a matter of accessing an internal private field. Unfortunately framework, such as the Binder Shell. Based on the Binder we have not been able to implement it yet. Shell, which emulates a system shell and runs on top of the E. JIDL tool smooved server, we have managed to manually register Binder The JIDL tool is in many ways similar to pidgen. It takes components. an interface and automatically generates code comprising Unfortunately, because of the SContext issue presented all interactions with Binder internals. By so doing, it eases in the previous section, we could not test our framework. the programmers burden to understand the entire framework Allthough we could not present empirical data, we consider before actually programming and also reduces the time of it to be common sense that the Java Binder framework offers development for applications. The JIDL tool has one advantage most feasible inter-process communication because instead of over the native OpenBinder tool: it used Java regular interfaces using sockets which are renowned for high latency as most IPC to define the agreement between Binders and Binder Proxies. solutions do, we implement our mechanism by calling into a By so doing, it takes advantage of the Reflecion API provided Linux kernel module which further pushes our transactions to by Java for retrieving method information and it also gains all the remote process. of the time wasted by pidgen to check the validity of the IDL VI.FUTUREWORK interface. We consider the OpenBinder framework as having the Being provided with a valid Java interface, JIDL’s function- highest priority, it being the core of our framework. In this ality can be sinthesized into the following steps: sense, not only do we plan on bringing the infrastructure up- • for each method generate a unique integer identifier to-date with the current Linux kernel, but we would also port and based on its signature generate the marshalling and it to other platforms as well, such as Windows or Mac OS X. unmarshalling code But also considering our encountered issues we feel it would • generate the Binder class - it is actually an abstract class be best to first re-implement the Package Manager from the as it does not offer implementation for the interface, it smooved server as to provide means to register OpenBinder is the programmer’s duty to provide such information components from external contexts. By so doing, we would after the code generation phase ends. The most important offer powerful justification for porting onto other platforms feature generated is the onTransact()’s body: it groups by means of a proof-of-concept implementation on Linux the unmarshalling code previously generated by unique systems. identifier for each method and invokes the cross-process interface methods (which will be implemented by the VII.CONCLUSIONS programmer). This ensures the closed loop, as the on- In conclusion, we sustain our initial motivation: Java needs Transact() method is invoked from native code when powerful and feasible inter-process communcation mecha- receiving a Binder transaction. nisms. As Android has prooved with their stunning success, the OpenBinder IPC model seems to be the most suitable solution for modern operating systems and we strongly feel that extending it into Java will have a major impact on the Java application development.

REFERENCES [1] Kees Jongenburger. Android binder, 2011. [2] Eugenia Loli-Queru. Introduction to openbinder and interview with dianne hackborn, January 2006. [3] OpenBinder. Openbinder, 2005. [4] Oracle. Remote method invocation home, 2012.