Java Openbinder Extension
Total Page：16
File Type：pdf, Size：1020Kb
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.