Android Binder驱动分析二 ServiceManager与binder驱动

偏执的太偏执、 2022-11-10 14:17 200阅读 0赞

[Android Binder驱动分析一 ServiceManager启动流程][Android Binder_ ServiceManager]

# 前言 #

本文可能涉及过多的`linux`内核知识，需要读者自行储备。  
上文我们尽在`framework`层分析了`ServiceManager`的启动流程，很多细节都没在binder驱动层面说明。  
本文使用3.18的内核版本,读者可自行下载 `https://source.android.com/devices/architecture/kernel/`

我们重新结合`binder`内核层代码看下`ServiceManager`启动流程.

`binder驱动`启动时会调用`init_binder_device`函数进程初始化，像`linux`注册一个驱动

//kernel/common/drivers/staging/android/binder.c
    //binder驱动代码
    
    //这个结构体用来描述用户空间的程序调用特定参数打开/dev/binder.c时函数映射表
    //比如open("/dev/binder.c")就是映射到binder_open
    //这里我们需要记住三个映射关系:
    // open 映射binder_open
    // mmap 映射binder_mmap
    //
    static const struct file_operations binder_fops = {
        
    	
    	.unlocked_ioctl = binder_ioctl, //unlocked_ioctl 描述ioctl函数  这个对应32位程序
    	.compat_ioctl = binder_ioctl, //compat_ioctl  描述ioctl函数  这个对应64位程序
    	.mmap = binder_mmap,
    	.open = binder_open,
    	
    };
    
    
    static int __init init_binder_device(const char *name)
    {
        
    	int ret;
    	struct binder_device *binder_device;
    	
    	binder_device = kzalloc(sizeof(*binder_device), GFP_KERNEL);
    	//映射表
    	binder_device->miscdev.fops = &binder_fops;
    	//驱动版本
    	binder_device->miscdev.minor = MISC_DYNAMIC_MINOR;
    	//驱动名
    	binder_device->miscdev.name = name;
    	
    	//略...
    	//注册一个驱动，且把函数关系表告诉linux
    	ret = misc_register(&binder_device->miscdev);
    	return ret;
    }

我们首先在回过看下`servicemanager`启动函数

//frameworks/base/cmds/servicemanager/service_manager.c
    //servicemanager代码
    
    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;
    }

首先查看`binder_open`

//frameworks/native/cmds/servicemanager/binder.c
    //servicemanager代码
    
    struct binder_state *binder_open(size_t mapsize)
    {
        
        struct binder_state *bs;
    
    	//这里分配内存
        bs = malloc(sizeof(*bs));
       
    	//打开binder驱动，并得到文件描述符 然后保存
    	//open进入内核分析
        bs->fd = open("/dev/binder", O_RDWR); ----------------------------------------------- 1
        //记录分配的内存大小 并保存
        bs->mapsize = mapsize;
     
        //mmap进入内核分析
        bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);------------------------------------2
        
        return bs;
    }

我们首先查看open对应`binder`驱动的代码

//kernel/common/drivers/staging/android/binder.c
    //binder驱动代码
    
    static int binder_open(struct inode *nodp, struct file *filp)
    {
        
    	//binder驱动会为每个打开驱动的进程创建一个binder_proc 
    	//binder_proc 保存了进程上下问信息等。且内部有若干个红黑树保存一些特殊信息
    	struct binder_proc *proc;
    	
    	struct binder_device *binder_dev;
    	//分配内存
    	proc = kzalloc(sizeof(*proc), GFP_KERNEL);
    	
    	//略... 一系列proc的初始化 
    	
    	binder_dev = container_of(filp->private_data, struct binder_device,
    				  miscdev);	
    	//记住后面mmap ioctl都会传入 struct file对象，而这个对象private_data会放入进程信息
    	filp->private_data = proc;
    
    	//binder_procs是binder驱动的1个链表,这个链表中每个节点都是hlist_node类型。
    	//proc中proc_node是hlist_node类型
    	//这里这句话大致用意是将当前进程的信息放入连表中
    	//这里大家不用太关心为什么不是直接放入proc，而是放入hlist_node类型。这里只需要知道binder驱动可以根据这个节点就可以找到proc对象
    	hlist_add_head(&proc->proc_node, &binder_procs);
    
    	return 0;
    }

总结：  
open函数主要是让`binder驱动`创建了`binder_proc`对象

`mmap`对应`binder`驱动的代码

//kernel/common/drivers/staging/android/binder.c
    //binder驱动代码
    
    static int binder_mmap(struct file *filp, struct vm_area_struct *vma)
    {
        
    
    	//vm_area_struct 标识程序的用户空间信息
    	int ret;
    	//这里open的时候会让filpprivate_data放入binder_proc 对象
    	struct binder_proc *proc = filp->private_data;
    	const char *failure_string;
    
    	//很重要背下来，binder驱动限制了映射空间最大为4MB 超过请求以4MB处理
    	//如果需要大内存共享请使用Ashmem(匿名共享内存)
    	if ((vma->vm_end - vma->vm_start) > SZ_4M)
    		vma->vm_end = vma->vm_start + SZ_4M;
    
    	vma->vm_flags = (vma->vm_flags | VM_DONTCOPY) & ~VM_MAYWRITE;
    	vma->vm_ops = &binder_vm_ops;
    	vma->vm_private_data = proc;
    	//这个函数主要是建立内核空间和用于空间的映射.
    	//源码位于kernel/common/drivers/staging/android/binder_alloc.c
    	//proc->alloc是一个binder_alloc结构体。这个结构体里面包含了映射信息
    	ret = binder_alloc_mmap_handler(&proc->alloc, vma);
    
    	return 0;
    	return ret;
    }

`binder_alloc`数据结构如下

//kernel/common/drivers/staging/android/binder_alloc.h
    
    struct binder_alloc {
        
        struct mutex mutex;
        struct vm_area_struct *vma;
        struct mm_struct *vma_vm_mm;
        void *buffer; // map 的地址就是这里了
        ptrdiff_t user_buffer_offset; //内核空间和用户空间的差
        struct list_head buffers; //所有的buffers列表
        struct rb_root free_buffers; //只进行了预定，没有分配，按大小排序
        struct rb_root allocated_buffers; //已经分配了,按地址排序
        size_t free_async_space; //用于异步请求的空间
        struct binder_lru_page *pages;//所有的pages
        size_t buffer_size; //总共的大小
        uint32_t buffer_free;
        int pid;
    };

`mmap` 函数主要就是做`serviceManager`之间做内存映射实现一次拷贝的概念,这里主要映射的内存只允许`serviceManager读`，不允许`serviceManager写`，如果`serviceManager`给`binder`传入信息或者回复其他`client`，都需要内存拷贝。而`binder`驱动给`serviceManager`发送则不需要.因为`binder`驱动可以读写这块内存。关于为什么只能读的问题可以看博主的第一篇文章，大致原因是`mmap`传入了一个只读的flag去打开驱动。

我们继续回头分析`service_manager`的`binder_become_context_manager`函数

//frameworks/base/cmds/servicemanager/service_manager.c
    //servicemanager代码
    
    int main(int argc, char **argv)
    {
        
    	//这个结构体保存mmap映射的一些信息，具体结构体可以看后文
        struct binder_state *bs;
    	//打开一个binder驱动,并且内部会调用mmap函数映射 
        bs = binder_open(128*1024);
       
    	//告诉binder驱动 自己是一个特殊service 也就是servicemanger。
        if (binder_become_context_manager(bs)) {
        
            ALOGE("cannot become context manager (%s)\n", strerror(errno));
            return -1;
        }
        return 0;
    }
    
    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);
    }

//kernel/common/drivers/staging/android/binder.c
    //binder驱动代码
    
    //ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
    //这里cmd是BINDER_SET_CONTEXT_MGR  arg是0
    static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
    {
        
    	int ret;
    	//oepn的时候包在filp的
    	struct binder_proc *proc = filp->private_data;
    	//binder_thread 代表一个service_manager的一个线程
    	//这里是表示当前调用这个ioctl的线程
    	//所有的service_manager进程都会被保存到binder_proc *proc的一个红黑树中
    	struct binder_thread *thread;
    	
    	unsigned int size = _IOC_SIZE(cmd);
    	
    	void __user *ubuf = (void __user *)arg;
    
    	binder_selftest_alloc(&proc->alloc);
    
    	
    	//这里时一个阻塞代码，如果binder_stop_on_user_error 大于2这里会被休眠
    	//这里先无视即可
    	ret = wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);
    	
    	//获取当前线程对应的结构体，如果没有创建过，那么就创建一个放入到proc的红黑树
    	thread = binder_get_thread(proc);
    
    
    	switch (cmd) {
        
    	case BINDER_WRITE_READ:
    		//....略
    	
    	case BINDER_SET_CONTEXT_MGR:
    		ret = binder_ioctl_set_ctx_mgr(filp, NULL);
    		
    		break;
    	
    		//....其他case略
    
    	}
    	ret = 0;
    
    	return ret;
    }

//kernel/common/drivers/staging/android/binder.c
    //binder驱动代码
    
    
    //flat_binder_object 这个传入的NULL，
    static int binder_ioctl_set_ctx_mgr(struct file *filp,
    				    struct flat_binder_object *fbo)
    {
        
    	int ret = 0;
    	struct binder_proc *proc = filp->private_data;
    	//context 存储了一些名字的等I西宁西
    	struct binder_context *context = proc->context;
    	//binder_node 数据结构 可以简单理解，它保存了用户空间各类service实现IBinder类的实体对象的指针。这个指针可以用来寻找到IBinder对象。关于
    	//这个对象后面我们在说
    	struct binder_node *new_node;
    
    	
    
    	if (uid_valid(context->binder_context_mgr_uid)) {
        
    		//..略
    	} else {
        
    		context->binder_context_mgr_uid = curr_euid;
    	}
    	
    	//构建一个节点
    	new_node = binder_new_node(proc, fbo);
    	
    	//引用计数方便管理
    	new_node->local_weak_refs++;
    	new_node->local_strong_refs++;
    	new_node->has_strong_ref = 1;
    	new_node->has_weak_ref = 1;
    	//servicemanager会讲这个node放入上下文中
    	//旧版本的内核会将这个对象放到一个全局静态变量binder_context_mgr_node 
    	context->binder_context_mgr_node = new_node;
    	//移除一些node临时数据
    	binder_put_node(new_node);
    
    	return ret;
    }

//kernel/common/drivers/staging/android/binder.c
    //binder驱动代码
    
    //fp 在servicemanager传入的是null
    static struct binder_node *binder_new_node(struct binder_proc *proc,
    					   struct flat_binder_object *fp)
    {
        
    	
    	struct binder_node *node;
    	
    	//分配内存
    	struct binder_node *new_node = kzalloc(sizeof(*node), GFP_KERNEL);
    
    	//初始化
    	node = binder_init_node_ilocked(proc, new_node, fp);
    
    
    	return node;
    }
    
    
    
    //new_node是一个分配内存的对象但是尚未初始化的
    //这个函数主要是将这个节点的属性赋值然后插入binder驱动的一个红黑树中
    //fp 是null
    static struct binder_node *binder_init_node_ilocked(
    						struct binder_proc *proc,
    						struct binder_node *new_node,
    						struct flat_binder_object *fp)
    {
        
    	struct rb_node **p = &proc->nodes.rb_node;
    	struct rb_node *parent = NULL;
    	struct binder_node *node;
    	//很显然 ptr是0
    	binder_uintptr_t ptr = fp ? fp->binder : 0;
    	//cookie  是0
    	binder_uintptr_t cookie = fp ? fp->cookie : 0;
    	// flags 是0
    	__u32 flags = fp ? fp->flags : 0;
    	
    	s8 priority;
    	//插入红黑树
    	while (*p) {
        
    		//略 这里没必要纠结如何插入，只需要知道被放入一个binder驱动的树中，有需要就取出来就好
    	}
    
    	//下面是对这个node的属性赋值，简单看看就行，需要的时候在分析，防止无法自拔
    	node = new_node;
    	binder_stats_created(BINDER_STAT_NODE);
    	node->tmp_refs++;
    	rb_link_node(&node->rb_node, parent, p);
    	rb_insert_color(&node->rb_node, &proc->nodes);
    	node->debug_id = atomic_inc_return(&binder_last_id);
    	node->proc = proc;
    	node->ptr = ptr;
    	node->cookie = cookie;
    	node->work.type = BINDER_WORK_NODE;
    	priority = flags & FLAT_BINDER_FLAG_PRIORITY_MASK;
    	node->sched_policy = (flags & FLAT_BINDER_FLAG_PRIORITY_MASK) >>
    		FLAT_BINDER_FLAG_SCHED_POLICY_SHIFT;
    	node->min_priority = to_kernel_prio(node->sched_policy, priority);
    	node->accept_fds = !!(flags & FLAT_BINDER_FLAG_ACCEPTS_FDS);
    	node->inherit_rt = !!(flags & FLAT_BINDER_FLAG_INHERIT_RT);
    	node->txn_security_ctx = !!(flags & FLAT_BINDER_FLAG_TXN_SECURITY_CTX);
    	spin_lock_init(&node->lock);
    	INIT_LIST_HEAD(&node->work.entry);
    	INIT_LIST_HEAD(&node->async_todo);
    
    
    	return node;
    }

总结binder\_become\_context\_manager函数做了如下几件事：

1.  创建了一个`binder_node`
2.  将新建的`binder_node`放入`servicemanager`的上下文`binder_context_mgr_node`中
3.  将新建的`binder_node`放入`binder`驱动的红黑树中

我们继续分析servicemanager最后一个函数 binder\_loop(bs, svcmgr\_handler);

//frameworks/base/cmds/servicemanager/service_manager.c
    
    int main(int argc, char **argv)
    {
        
    	//这个结构体保存mmap映射的一些信息，具体结构体可以看后文
        struct binder_state *bs;
    	
    	//略
    	//死循环，不断读取从binder驱动传来的信息，然后调用svcmgr_handler函数去处理
        binder_loop(bs, svcmgr_handler);
    
        return 0;
    }

//frameworks/base/cmds/servicemanager/service_manager.c
    //servicemanager代码
    
    void binder_loop(struct binder_state *bs, binder_handler func)
    {
        
        int res;
        struct binder_write_read bwr;
        uint32_t readbuf[32];
    
        bwr.write_size = 0;
        bwr.write_consumed = 0;
        bwr.write_buffer = 0;
    
        readbuf[0] = BC_ENTER_LOOPER;
        
        //我们首先分析这个
        binder_write(bs, readbuf, sizeof(uint32_t));
    
        for (;;) {
        
           //略
        }
    }
    
    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;
        res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
        if (res < 0) {
        
            fprintf(stderr,"binder_write: ioctl failed (%s)\n",
                    strerror(errno));
        }
        return res;
    }

`ioctl(bs->fd, BINDER_WRITE_READ, &bwr);` 这个函数将是我们第一次看到内核读取`servicemanager`的用户空间数据.这里`binder驱动`回将用户空间数据拷贝到内核.  
这里首先记住`binder_write_read` 对象的`read_size` 是0，`write_size` 是内容大小,`write_buffer` 是一个字符`BC_ENTER_LOOPER`,这里表示让binder驱动去读数据，而不是让其写入。

//kernel/common/drivers/staging/android/binder.c
    //binder驱动代码
    
    //`ioctl(bs->fd, BINDER_WRITE_READ, &bwr);`
    //参数 cmd ---- BINDER_WRITE_READ
    //参数 arg -----指向用户空间一个binder_write_read结构体的指针，记住这个指针是指向用户空间的地址！！！
    static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
    {
        
    	int ret;
    	struct binder_proc *proc = filp->private_data;
    	struct binder_thread *thread;
    	unsigned int size = _IOC_SIZE(cmd);
    	
    
    
    	switch (cmd) {
        
    	case BINDER_WRITE_READ:
    		ret = binder_ioctl_write_read(filp, cmd, arg, thread);
    		break;
    	
    	}
    	ret = 0;
    
    	return ret;
    }
    
    
    //参数 cmd ---- BINDER_WRITE_READ
    //参数 arg -----指向用户空间一个binder_write_read结构体的指针，记住这个指针是指向用户空间的地址！！！
    static int binder_ioctl_write_read(struct file *filp,
    				unsigned int cmd, unsigned long arg,
    				struct binder_thread *thread)
    {
        
    	int ret = 0;
    	
    	struct binder_proc *proc = filp->private_data;
    	
    	
    	void __user *ubuf = (void __user *)arg;
    	
    	struct binder_write_read bwr;
    
    
    	//从用户空间的ubuf所指向的地址拷贝 sizeof(bwr)大小的数据到内核空间
    	//copy_from_user linux内核api
    	if (copy_from_user(&bwr, ubuf, sizeof(bwr))) {
        
    		//拷贝失败返回
    		ret = -EFAULT;
    		goto out;
    	}
    	
    	//如果write_size 大于0那么证明是要从用户空间读取数据
    	if (bwr.write_size > 0) {
        
    		ret = binder_thread_write(proc, thread,
    					  bwr.write_buffer,
    					  bwr.write_size,
    					  &bwr.write_consumed);
    		//ret 返回0			  
    		if (ret < 0) {
        
    			bwr.read_consumed = 0;
    			if (copy_to_user(ubuf, &bwr, sizeof(bwr)))
    				ret = -EFAULT;
    			goto out;
    		}
    	}
    	//如果read_size 大于0那么证明是servicemanager要读binder的数据
    	if (bwr.read_size > 0) {
        
    		//略
    	}
    	
    	//binder读取传入的数据时会不断修改bwr.consumed 大小，标识binder驱动读取多少的传入数据
    	//servicemanager(可以读取这个得到服务端是否读取了)
    	if (copy_to_user(ubuf, &bwr, sizeof(bwr))) {
        
    		ret = -EFAULT;
    		goto out;
    	}
    out:
    	return ret;
    }

接下来要分析`binder_thread_write`函数，由于这个函数过分的长我们这里会大量裁剪

//binder_buffer是一个指针指向用户空间的某段数据
    //size 表示binder_buffer读取的大小
    //consumed 指针，指向这个binder_buffer
    static int binder_thread_write(
    			struct binder_proc *proc,
    			struct binder_thread *thread,
    			binder_uintptr_t binder_buffer, 
    			size_t size,
    			binder_size_t *consumed)
    {
        
    	struct binder_context *context = proc->context;
    	
    	void __user *buffer = (void __user *)(uintptr_t)binder_buffer;
    	//内核要读取用户空间的数据的起始指针位置
    	void __user *ptr = buffer + *consumed;
    	//要读用户空间数据的结束指针位置
    	void __user *end = buffer + size;
    	while (ptr < end && thread->return_error.cmd == BR_OK) {
        
    	
    		int ret;
    		//拷贝用户空间的ptr的前4字节到cmd中
    		if (get_user(cmd, (uint32_t __user *)ptr))
    			return -EFAULT;
    		//指针后移	
    		ptr += sizeof(uint32_t);
    
    		switch (cmd) {
        
    			case BC_ENTER_LOOPER:
    			//简单设置线程的一个状态就返回
    			thread->looper |= BINDER_LOOPER_STATE_ENTERED;
    			break;
    		}
    		*consumed = ptr - buffer;
    	}
    		return 0;
    }

我们继续binder\_loop

//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 bwr;
        //用于像驱动发送读写一块内存
        uint32_t readbuf[32];
    
        bwr.write_size = 0;
        bwr.write_consumed = 0;
        bwr.write_buffer = 0;
    
    
    	//这里for循环 大致的可以理解循环检测binder驱动是否给我们发消息。没有就休眠
        for (;;) {
        
            bwr.read_size = sizeof(readbuf); -----------------------想要从binder驱动读数据的大小
            bwr.read_consumed = 0;                 
            bwr.read_buffer = (uintptr_t) readbuf; -----------------------想要从binder驱动读数据的内存区域，这里是指针
    		//由于 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);
           
        }
    }

由于`binder`驱动一般不会主动像`servicemanager`发送信息所以我们就暂时分析到这里，后续文章讲通过一个文章分析`client`和`servicemanager`通信的流程

参考：  
[Binder 内存分配][Binder]

[Android Binder_ ServiceManager]: https://fanmingyi.blog.csdn.net/article/details/114551568
[Binder]: https://blog.csdn.net/xqyphp/article/details/78190553