First, Binder before the text

1. The concept:

In short, a Binder is an interprocess communication mechanism

2. Why Binder for Android

The Android system is based on the Linux kernel, which has provided IPC mechanisms such as pipes, message queues, shared memory and sockets. So why does Android provide Binder for IPC? Mainly based on performance, stability and security several reasons.

3. The performance

Let’s start with the performance advantages. Socket, as a universal interface, has low transmission efficiency and high cost. It is mainly used for inter-process communication across the network and low-speed communication between processes on the local machine. Message queues and pipes adopt store-and-forward mode, that is, data is copied from the sender cache to the cache created by the kernel, and then copied from the kernel cache to the receiver cache at least twice. Although shared memory does not require copying, it is difficult to control and use. Binders require only one copy of data and are second only to shared memory in performance.

Stability of 4.

Binder is based on C/S architecture, with a clear architecture, clear responsibilities and mutual independence, resulting in better stability. Shared memory does not require copying, but is controlled and difficult to use. Binder mechanisms are superior to memory sharing from a stability perspective.

5. Security

Another aspect is security. As an open platform, Android has a large number of applications for users to install, so security is extremely important for the Android platform. As a user, of course, we don’t want the APP we download to secretly read my contacts, upload my private data, steal traffic and consume mobile phone power in the background. Traditional IPC has no security measures and relies entirely on upper-layer protocols to ensure that. First, the traditional IPC receiver cannot obtain the reliable process user ID/ process ID (UID/PID) of the other party, so it cannot identify the other party. Android assigns its own UID to each installed APP, so a process’s UID is an important indicator of the process’s identity. Traditional IPC can only be filled with UID/PID by the user in the packet, but this is unreliable and easy to be exploited by malicious programs. Reliable identity is only added in the kernel by the IPC mechanism. Secondly, the traditional IPC access points are open. As long as the program knows that these access points can establish a connection with the peer end, no matter what, it cannot prevent malicious programs from guessing the address of the receiver to get a connection. Binder supports both real name Binder and anonymous Binder for high security. \

The principle of traditional interprocess communication under Linux

\

1. Several concepts are involved:

  • Process isolation simply means that in the operating system, the memory between processes is not shared. Two processes are like two parallel worlds. Process A has no direct access to process B’s data, which is A popular definition of process isolation. Data interaction between processes A and B requires A special communication mechanism: inter-process communication (IPC).
  • Today’s operating systems use virtual storage, and for 32-bit systems, the addressing space (virtual storage) is 2 ^ 32, or 4GB. The core of the operating system is the kernel, independent of ordinary applications, which can access the protected memory space and access the permissions of the underlying hardware devices. To protect User processes from directly operating the Kernel and ensure Kernel security, the operating system logically divides the virtual Space into User Space and Kernel Space. For Linux, the maximum 1GB byte is used by the kernel, which is called kernel space. The lower 3GB bytes are used by each process and are called user space.
  • Although there is a logical division between user space and kernel space, it is inevitable that the user space needs to access kernel resources, such as file operations, network access, and so on. To break through the isolation constraints, you need to do this with system calls. System call is the only way for user space to access the kernel space, which ensures that all resource access is under the control of the kernel, avoiding user programs’ unauthorized access to system resources, and improving system security and stability.

Linux uses two levels of protection: level 0 for the system kernel and level 3 for user programs. When a task (process) executing a system call is trapped in kernel code, the process is said to be in kernel running state (kernel-state). The processor executes in kernel code with the highest privilege (level 0). When a process is in kernel state, the kernel code executed uses the kernel stack of the current process. Each process has its own kernel stack. When a process is executing the user’s own code, it is said to be in user mode. At this point the processor runs in the lowest privilege level (level 3) of user code.

2. A brief introduction of traditional communication principles

The usual practice is that the data that the message sender is about to send is stored in an in-memory cache, which is put into kernel mode through a system call. The kernel allocates memory in the kernel space, creates a kernel cache, and calls copy_from_user() to copy data from the user-space memory cache to the kernel cache in the kernel space. Similarly, when receiving data, the recipient process creates a memory cache in its own user space, and the kernel program calls copy_to_user() to copy the data from the kernel cache to the recipient process’s memory cache. In this way, the data sender process and the data receiver process have completed a data transfer, which is called an inter-process communication. The diagram below:

3. Disadvantages of the traditional IPC communication method \

  • Performance is poor. One data transfer requires two data copies: memory cache > kernel cache > memory cache.
  • Receive data buffer provided by the data receiving process, but the receiving process may not know how much space to store data to be passed, therefore can only be set up as large memory space or to call API to receive the size of the header to get the message body, the two is not a waste of space is a waste of time.

3. Cross-process communication principle of Binder

1. Several concepts are involved:

  • Dynamic kernel loadable modules A module is a stand-alone program that can be compiled separately but cannot be run independently. It is linked to the kernel at run time and runs as part of the kernel. In this way, the Android system can dynamically add a kernel module that runs in the kernel space and acts as a bridge for communication between user processes. Binder Dirver is a kernel module that runs in the Android kernel space and is responsible for communication between user processes through Binder.
  • Memory mapping The Memory mapping involved in the Binder IPC mechanism is implemented through Mmap (), which is a method of memory mapping in operating systems. Memory mapping simply means mapping a memory region of user space to kernel space. After the mapping relationship is established, the modification of the memory area can be directly reflected in the kernel space. Conversely, changes made to this area in kernel space can be directly reflected in user space. Memory mapping can reduce the number of data copies and realize efficient interaction between user space and kernel space. The modification of the two Spaces can be directly reflected in the mapped memory area, thus being timely sensed by the other space. Because of this, memory mapping can provide support for interprocess communication.

2.Binder IPC implementation steps:

  • First, the Binder driver creates a data receive cache in kernel space.
  • Then, a kernel cache is created in the kernel space, and the mapping relationship between the kernel cache and the kernel data receiving cache, as well as the mapping relationship between the kernel data receiving cache and the user space address of the receiving process is established.
  • The sender process uses the system call copy_from_user() to copy the data to the kernel cache in the kernel. Since there is a memory mapping between the kernel cache and the user space of the receiving process, the data is sent to the user space of the receiving process, thus completing an inter-process communication. The diagram below:

4. Communication process with Binder

A complete interprocess communication must contain at least two processes, which are usually called Client and Server respectively. Binder is necessary to realize communication due to process isolation mechanism.

1. Internet Communication process:

Includes Client, Server, ServiceManager, and Binder drivers. Client, Server, Service Manager run in user space, Binder drivers run in kernel space. Service Manager and Binder drivers are provided by the system, while Client and Server are implemented by applications. Client, Server, and ServiceManager use system calls open, mmap, and IOCtl to access the device file /dev/binder and interact with binder drivers to achieve indirect cross-process communication. As shown below: \

Client, Server, ServiceManager, Binder The roles that drive these components in communication are similar to the relationships among Servers, clients, ServiceManager, and routers (Binder drivers) in the Internet. The usual way to visit a web page is like this: first enter an address in the browser, such as www.google.com, and then press enter. However, there is no way to directly find the server we want to visit through the domain name address. Therefore, we need to visit the DNS domain name server first. The DNS domain name server saves the IP address 10.249.23.13 corresponding to www.google.com. Then the IP address can be used to put to the server corresponding to www.google.com.

2. Communication process with Binder:

The communication process of Binder can be roughly summarized:

  • First, a process registers itself as a ServiceManager with the Binder driver using the BINDER_SET_CONTEXT_MGR command.

\

  • A Server registers a Binder (a Binder entity in a Server) with a ServiceManager to provide services. The driver creates entity nodes in the kernel for the Binder and references to the entity by the ServiceManager, packages the name and the new reference to the ServiceManager, and the ServiceManger fills it in the lookup table.

\

  • With the help of Binder drivers, clients get references to Binder entities from ServiceManager by name and communicate with Server processes through this reference.


\

\

This article is from the research and development team of one point information product