Android Binder驱动分析一 ServiceManager启动流程

柔光的暖阳◎ 2022-11-06 08:56 197阅读 0赞

# 前言 #

`Android`存在众多敏感资源，如媒体播放器等,如果让用户程序随意乱来会出现各种流氓行为。所以  
`Android`系统对于敏感资源的访问，要求应用程序通过内置的各种服务(`service`)桥接访问,如`MediaPlayService`。

但是应用程序怎么查询`MediaPlayService`的桥接入口？ 这是由另一个系统服务`ServiceManager`统一管理的。

请务必熟悉`linux mmap`的`api`的使用。可参阅博主其他博文[linux mmap函数][linux mmap]

`ServiceManager`会在`linux`读取`init.rc`中启动,而后作为整个`Android`系统第一个打开`binder`驱动的程序。

`ServiceManager`程序入口如下：

//frameworks/base/cmds/servicemanager/service_manager.c
    
    int main(int argc, char **argv)
    {
        
    	//这个结构体保存mmap映射的一些信息，具体结构体可以看后文
        struct binder_state *bs;
    	//打开一个binder驱动,并且内部会调用mmap函数映射
        bs = binder_open(128*1024);
        if (!bs) {
        
            ALOGE("failed to open binder driver\n");
            return -1;
        }
    	//告诉binder驱动 自己是一个特殊service 也就是servicemanger。
        if (binder_become_context_manager(bs)) {
        
            ALOGE("cannot become context manager (%s)\n", strerror(errno));
            return -1;
        }
    	//死循环，不断读取从binder驱动传来的信息，然后调用svcmgr_handler函数去处理
        binder_loop(bs, svcmgr_handler);
    
        return 0;
    }

总结就做了三件事：  
1 打开`binder`驱动  
2 告诉`binder`驱动自己是`servicemanager`  
3 不断的循环读取`binder`驱动传来的信息，然后进行处理

//frameworks/base/cmds/servicemanager/binder.c
    struct binder_state
    {
        
    	//打开的/dev/binder 后的文件描述符
        int fd;
        //映射空间的起始地址
        void *mapped;
        //映射空间的的大小.service_manager的大小为128k
        unsigned mapsize;
    };

//frameworks/native/cmds/servicemanager/binder.h
    #define BINDER_SERVICE_MANAGER  0U

根据上面的三个步骤我们来逐步分析下源码流程

//frameworks/native/cmds/servicemanager/binder.c
    struct binder_state *binder_open(size_t mapsize)
    {
        
        struct binder_state *bs;
    
    	//这里分配内存
        bs = malloc(sizeof(*bs));
       
    	//打开binder驱动，并得到文件描述符 然后保存
    	//O_RDWR标识我们可以利用这个文件标识符进行读写，然而后续的mmap的返回文件描述仅读！！！注意，我发现很多文字没写清楚，就谈一次拷贝的概念。
        bs->fd = open("/dev/binder", O_RDWR);
        //记录分配的内存大小 并保存
        bs->mapsize = mapsize;
        //进行内核空间内存和用户空间内存映射。这里会回调到binder驱动的实现类的binder_mmap函数。（binder属于内核）
        //第一个参数：NULL即可，除非你要高度自定义映射区域地址 
        //第二个参数: mapsize 映射内存大小，注意binder内核设置上限为4mb，这里传入的大小为128k
        //第三个参数：PROT_READ标识这个文件描述只能在用户控件读但不能写，除非你设置PROT_WRITE。当然binder驱动可以写入
        //第四个参数: MAP_PRIVATE标识当前当前读写文件描述符操作不会同步到文件中，且不能和其他进程共享。
        //第五个参数：0 映射偏移 
        //注意: 1 mmap返回内存区域我们只能读但不能写，也就是binder驱动给我们回信息的时候，不需要拷贝内存到用户空间(一次拷贝的概念)
        //注意: 2 我们给binder驱动发消息的时候不管是serive还是client都要进行一次内存上的拷贝到内核空间 
        // 总结： bs->mapped 只能读取 ，   bs->fd 可读写
        bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);
        
        return bs;
    }

//frameworks/native/cmds/servicemanager/binder.c
    int binder_become_context_manager(struct binder_state *bs)
    {
        	
    	//ioctl是linux的一个api，可以调用这个将数据拷贝到指定的文件描述符上。这里会将用户空间内存拷贝到内核空间
    	//bs->fd可读写，但是必须要做内存在内核和用户空间的交互
    	//bs->mapped  智能读不可写，只有binder驱动能写入。如果binder驱动写入，因为存在内存映射就不需要内存拷贝
    	//也就是说 binder一次拷贝体现在读，而不体现在写
        return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
    }

//./external/kernel-headers/original/uapi/linux/binder.h
    
    #ifdef BINDER_IPC_32BIT
    typedef __u32 binder_size_t;
    typedef __u32 binder_uintptr_t;
    #else
    typedef __u64 binder_size_t;
    typedef __u64 binder_uintptr_t;
    #endif
    
    /*
     * On 64-bit platforms where user code may run in 32-bits the driver must
     * translate the buffer (and local binder) addresses appropriately.
     */
    
    struct binder_write_read {
        
    	binder_size_t		write_size;	/* bytes to write */
    	binder_size_t		write_consumed;	/* bytes consumed by driver */
    	binder_uintptr_t	write_buffer;
    	binder_size_t		read_size;	/* bytes to read */
    	binder_size_t		read_consumed;	/* bytes consumed by driver */
    	binder_uintptr_t	read_buffer;
    };

我们关注下上述代码的`binder_write(bs, readbuf, sizeof(uint32_t))`函数如何给`binder`发送消息,

//frameworks/native/cmds/servicemanager/binder.c
    
    /* 
    struct binder_write_read bwr;
        //给bwr.read_buffer一个指向，用于让驱动读取
        uint32_t readbuf[32];
    	//这里发送信息告诉binder驱动自己进入死循环，会在循环中读取binder驱动发来的信息
        readbuf[0] = BC_ENTER_LOOPER;
        //直接写入到驱动中 ----------- (1)
        binder_write(bs, readbuf, sizeof(uint32_t));----------- (1)
    */
    
    // 第一个参数 binder_state *bs 保存mmap后映射信息
    // 第二个参数 指向要写入到binder驱动的数据的地址
    // 第三参数 写入的到binder驱动的大小
    int binder_write(struct binder_state *bs, void *data, size_t len)
    {
        
        struct binder_write_read bwr;
        
        //标识写入结果
        int res;
    	
        bwr.write_size = len;
        bwr.write_consumed = 0;
        //要时刻记得这个保存的指针
        bwr.write_buffer = (uintptr_t) data;
        bwr.read_size = 0;
        bwr.read_consumed = 0;
        bwr.read_buffer = 0;
        //ioctl是linux 的api可以直接把数据发送binder驱动
        //第一个参数 binder的文件描述。上文说过bs->fd可读写。
        //第二个参数 BINDER_WRITE_READ binder驱动顶一个标识符，标识要读写
        //第三个参数 要读的数据的指针
        res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
        
        return res;
    }

我们最后在分析下`binder_loop`函数最后的for循环

//frameworks/native/cmds/servicemanager/binder.c
    
    //参数1： struct binder_state *bs 记录mmap映射信息
    //参数2： binder_handler 函数指针 指向service_manager.c的 svcmgr_handler函数
    void binder_loop(struct binder_state *bs, binder_handler func)
    {
        
    	
        int res;
        //内部的数据结构可以看下文
        //
        //			struct binder_write_read {
        
    	//				binder_size_t		write_size;	要写入的数据的大小
    	//			    binder_size_t		write_consumed;	 驱动会去消费传入的数据，消费多少个写入字节就会标识在这
    	//				binder_uintptr_t	write_buffer; 指向写入数据的指针
    	//				binder_size_t		read_size;	要被读取的字节大小
    	//				binder_size_t		read_consumed;	binder驱动要写入的给读取端的字节数 等价read_buffer
    	//				binder_uintptr_t	read_buffer; 指向读取区域的指针
    	//			};
        //
        struct binder_write_read bwr;
        //用于像驱动发送读写一块内存
        uint32_t readbuf[32];
    
        bwr.write_size = 0;
        bwr.write_consumed = 0;
        bwr.write_buffer = 0;
    
    	//这里发送信息告诉binder驱动自己进入死循环，会在循环中读取binder驱动发来的信息
        readbuf[0] = BC_ENTER_LOOPER;
        //直接写入到驱动中 ----------- (1)
        binder_write(bs, readbuf, sizeof(uint32_t));----------- (1)
    	//这里for循环 大致的可以理解循环检测binder驱动是否给我们发消息。没有就休眠
        for (;;) {
        
            bwr.read_size = sizeof(readbuf);
            bwr.read_consumed = 0;
            bwr.read_buffer = (uintptr_t) readbuf;
    		//由于 bwr.write_consumed = 0; 所以这里是servicemanager想要binder驱动返回消息
    		//如果binder驱动没有信息，那么阻塞线程即可
    		//bwr会被binnder驱动写入。
            res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
    
            if (res < 0) {
        
                ALOGE("binder_loop: ioctl failed (%s)\n", strerror(errno));
                break;
            }
    		//解析参数
            res = binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func);
            if (res == 0) {
        
                ALOGE("binder_loop: unexpected reply?!\n");
                break;
            }
            if (res < 0) {
        
                ALOGE("binder_loop: io error %d %s\n", res, strerror(errno));
                break;
            }
        }
    }

`binder_write_read`是`binder驱动`和`service之间`沟通的数据结构,而`client`发来的信息的数据结构是`binder_transaction_data`.

`binder_parse`是解析`binder驱动`信息，我们还必须解析成客户端发来的数据格式，解析之后就是客户端发来的数据  
于是调用`svcmgr_handler`进行处理客户端消息

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70]

> tip：mmap共享内存的区域存放的数据时binder\_transaction\_data。不是binder\_write\_read数据，请务必记下

//frameworks/native/cmds/servicemanager/binder.c
    
    //binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func);
    int binder_parse(struct binder_state *bs, // mmap后的内存映射信息
    				 struct binder_io *bio,   // 0
    				 uintptr_t ptr,       	  // 一个指针，指向uint32_t readbuf[32];内存区域
                     size_t size,			  // 本质是bwr.read_consumed 表示binder写出的大小	
                     binder_handler func	  // 解析传过来的数据后调用func函数，实际是svcmgr_handler函数
                    )
    {
        
        int r = 1;
        //指向uint32_t readbuf[32];最后一个内存字节
        uintptr_t end = ptr + (uintptr_t) size;
    	//不断遍历这个内存区域，取出binder驱动写入的数据
        while (ptr < end) {
        
        	//取出内存区域的前4个字节内容，前四个字节存储的是一些枚举类型
        	//这些类型标识了binder驱动要告诉serviceManager 要做什么，和怎么做。
        	//比如cmd等于BR_TRANSACTION的话，你就继续读取ptr后面的内容并解析为 (struct binder_transaction_data *) 
            uint32_t cmd = *(uint32_t *) ptr;
            //指针位置向后偏移
            ptr += sizeof(uint32_t);
    
            switch(cmd) {
        
            case BR_NOOP:
                break;
            case BR_TRANSACTION_COMPLETE:
                break;
            case BR_INCREFS:
            case BR_ACQUIRE:
            case BR_RELEASE:
            case BR_DECREFS:
                ptr += sizeof(struct binder_ptr_cookie);
                break;
            
            //这个标志 是binder驱动告诉service，我发了一些额外的操作信息，
            //你先读取继续读取ptr内容并翻译为struct binder_transaction_data
            //然后根据struct binder_transaction_data 内容继续操作具体内容
            case BR_TRANSACTION: {
        
            
                struct binder_transaction_data *txn = (struct binder_transaction_data *) ptr;
             
                if (func) {
        
                    unsigned rdata[256/4];
                    struct binder_io msg;
                    struct binder_io reply;
                    int res;
    				//binder_io是一个用于简化binder_transaction_data读写的数据结构
                    bio_init(&reply, rdata, sizeof(rdata), 4);
                    //将binder_transaction_data 数据拷贝到binder_io中
                    bio_init_from_txn(&msg, txn);
                    //解析传入的数据后进行下一步操作
                    res = func(bs, txn, &msg, &reply);
                    //答复对方 先不深究
                    binder_send_reply(bs, &reply, txn->data.ptr.buffer, res);
                }
                ptr += sizeof(*txn);
                break;
            }
            case BR_REPLY: {
        
                struct binder_transaction_data *txn = (struct binder_transaction_data *) ptr;
                if ((end - ptr) < sizeof(*txn)) {
        
                    ALOGE("parse: reply too small!\n");
                    return -1;
                }
                binder_dump_txn(txn);
                if (bio) {
        
                    bio_init_from_txn(bio, txn);
                    bio = 0;
                } else {
        
                    /* todo FREE BUFFER */
                }
                ptr += sizeof(*txn);
                r = 0;
                break;
            }
          	//...略
         
            }
        }
    
        return r;
    }

`binder_transaction_data` 数据结构如下，后续文章在做分析

//./external/kernel-headers/original/uapi/linux/binder.h
    
    #ifdef BINDER_IPC_32BIT
    typedef __u32 binder_size_t;
    typedef __u32 binder_uintptr_t;
    #else
    typedef __u64 binder_size_t;
    typedef __u64 binder_uintptr_t;
    #endif
    
    struct binder_transaction_data {
        
    	/* The first two are only used for bcTRANSACTION and brTRANSACTION,
    	 * identifying the target and contents of the transaction.
    	 */
    	union {
        
    		__u32	handle;	/* target descriptor of command transaction */
    		binder_uintptr_t ptr;	/* target descriptor of return transaction */
    	} target;
    	binder_uintptr_t	cookie;	/* target object cookie */
    	__u32		code;		/* transaction command */
    
    	/* General information about the transaction. */
    	__u32		flags;
    	pid_t		sender_pid;
    	uid_t		sender_euid;
    	binder_size_t	data_size;	/* number of bytes of data */
    	binder_size_t	offsets_size;	/* number of bytes of offsets */
    
    	/* If this transaction is inline, the data immediately
    	 * follows here; otherwise, it ends with a pointer to
    	 * the data buffer.
    	 */
    	union {
        
    		struct {
        
    			/* transaction data */
    			binder_uintptr_t	buffer;
    			/* offsets from buffer to flat_binder_object structs */
    			binder_uintptr_t	offsets;
    		} ptr;
    		__u8	buf[8];
    	} data;
    };

在解析出`binder`发来的数据后,我们将得到客户端发来的真正数据结构`binder_transaction_data`，但是该结构使用上太复杂，于是乎我们又用了一个新的数据结构`binder_io`去简化`binder_transaction_data`的数据读取和写入

`svcmgr_handler`函数如下：  
我们只需要知道`serviceManager`会根据传入的命令进行操作即可，后文会细致分析

//frameworks/base/cmds/servicemanager/service_manager.c
    /*
       				unsigned rdata[256/4];
                    struct binder_io msg;
                    struct binder_io reply;
                    int res;
                    bio_init(&reply, rdata, sizeof(rdata), 4);
                    bio_init_from_txn(&msg, txn);
                    res = func(bs, txn, &msg, &reply);
    */
    int svcmgr_handler(struct binder_state *bs,
                       struct binder_transaction_data *txn,
                       struct binder_io *msg,
                       struct binder_io *reply)
    {
        
        struct svcinfo *si;
        uint16_t *s;
        size_t len;
        uint32_t handle;
        uint32_t strict_policy;
        int allow_isolated;
    
       
    
        // Equivalent to Parcel::enforceInterface(), reading the RPC
        // header with the strict mode policy mask and the interface name.
        // Note that we ignore the strict_policy and don't propagate it
        // further (since we do no outbound RPCs anyway).
        strict_policy = bio_get_uint32(msg);
        s = bio_get_string16(msg, &len);
        if (s == NULL) {
        
            return -1;
        }
    
        if ((len != (sizeof(svcmgr_id) / 2)) ||
            memcmp(svcmgr_id, s, sizeof(svcmgr_id))) {
        
            fprintf(stderr,"invalid id %s\n", str8(s, len));
            return -1;
        }
    
        if (sehandle && selinux_status_updated() > 0) {
        
            struct selabel_handle *tmp_sehandle = selinux_android_service_context_handle();
            if (tmp_sehandle) {
        
                selabel_close(sehandle);
                sehandle = tmp_sehandle;
            }
        }
    
        switch(txn->code) {
        
        case SVC_MGR_GET_SERVICE:
        case SVC_MGR_CHECK_SERVICE:
            s = bio_get_string16(msg, &len);
            if (s == NULL) {
        
                return -1;
            }
            handle = do_find_service(bs, s, len, txn->sender_euid, txn->sender_pid);
            if (!handle)
                break;
            bio_put_ref(reply, handle);
            return 0;
    
        case SVC_MGR_ADD_SERVICE:
        	//
            s = bio_get_string16(msg, &len);
            if (s == NULL) {
        
                return -1;
            }
            handle = bio_get_ref(msg);
            allow_isolated = bio_get_uint32(msg) ? 1 : 0;
            if (do_add_service(bs, s, len, handle, txn->sender_euid,
                allow_isolated, txn->sender_pid))
                return -1;
            break;
    
        case SVC_MGR_LIST_SERVICES: {
        
            uint32_t n = bio_get_uint32(msg);
    
            if (!svc_can_list(txn->sender_pid)) {
        
                ALOGE("list_service() uid=%d - PERMISSION DENIED\n",
                        txn->sender_euid);
                return -1;
            }
            si = svclist;
            while ((n-- > 0) && si)
                si = si->next;
            if (si) {
        
                bio_put_string16(reply, si->name);
                return 0;
            }
            return -1;
        }
        default:
            ALOGE("unknown code %d\n", txn->code);
            return -1;
        }
    
        bio_put_uint32(reply, 0);
        return 0;
    }

`binder_io`结构体如下:  
可先不细节

//frameworks\native\cmds\servicemanager\binder.h
    struct binder_io
    {
        
        char *data;            /* pointer to read/write from */
        binder_size_t *offs;   /* array of offsets */
        size_t data_avail;     /* bytes available in data buffer */
        size_t offs_avail;     /* entries available in offsets array */
    
        char *data0;           /* start of data buffer */
        binder_size_t *offs0;  /* start of offsets buffer */
        uint32_t flags;
        uint32_t unused;
    };

`ServiceManager`是一个单线程的进程,并不会多开线程处理请求

# 常用的一些方便查找文件命令 #

#查找当前文件夹或者子目录下文件名为binder.h的文件，然后在通过grep命令过滤 
    #grep也支持文件过滤，但是find有更多的选项
    find . -iname "binder.h" -exec grep -l  -E "struct.+binder_write_read.*{" -s  {
        } \;

[linux mmap]: https://blog.csdn.net/qfanmingyiq/article/details/114762889?spm=1001.2014.3001.5501
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmYW5taW5neWlx_size_16_color_FFFFFF_t_70]: /images/20221023/75517407bb86490b9a1a43db905068f3.png