移动虚拟化场景中多Android系统复用BinderIPC机制的方法

文档序号:6517118阅读:394来源:国知局
移动虚拟化场景中多Android系统复用Binder IPC机制的方法
【专利摘要】本发明公开了一种移动虚拟化场景中多Android系统复用Binder?IPC机制的方法,方法包括:在宿主机中的Android系统中创建一个虚拟Binder设备驱动,并且使用该虚拟Binder设备驱动向Linux内核注册多个虚拟Binder设备,将虚拟Binder设备对应的设备文件分配给各个虚拟机;虚拟机发出Binder设备的访问请求时,首先调用虚拟Binder设备驱动,继而通过该虚拟Binder设备驱动将使用请求转发给真实Binder设备驱动;虚拟Binder设备驱动将操作转发给真实Binder设备的过程中,对冲突的服务名进行相应的拦截、过滤和修改。本发明在实现多Android系统运行下保证了系统性能的高效性。
【专利说明】移动虚拟化场景中多Android系统复用Binder IPC机制的方法
【技术领域】
[0001]本发明涉及计算机虚拟化【技术领域】,尤其涉及Android系统虚拟化中多个系统复用Binder IPC机制的方法。
【背景技术】
[0002]在Android操作系统的用户量迅速增长的背景下,其安全性也受到越来越广泛的关注。由于Android缺乏像iOS那样封闭的生态系统,恶意软件已经成为其安全性的最大威胁。为了限制恶意软件的活动范围,最大限度地保护用户的个人信息,有人提出了 Android虚拟化这一解决方案。Android虚拟化是指在一台设备上运行多个Android操作系统,这些操作系统相互隔离,安装在某一个系统中的应用软件无法对其它系统构成影响。这样就可以将用户的个人信息封锁在某一个系统中,即使其它系统中安装了恶意软件也不会对个人信息构成威胁。目前的虚拟化方案包括:完全虚拟化、半虚拟化以及基于容器的虚拟化,其中半虚拟化和基于容器的虚拟化统称为轻量级虚拟化。在这些虚拟化解决方案中,基于容器的轻量级虚拟化在性能方面相对其它方案具有很大的性能优势。
[0003]Binder IPC机制是Android操作系统最重要的特性之一,系统中几乎所有的进程间通信都通过Binder机制实现。所谓复用Binder IPC机制,是指Binder IPC机制的核心组件(如Binder设备驱动、Service Manager)由宿主机提供,虚拟机则没有这些组件,虚拟机中的进程通过一个虚拟设备间接地使用宿主机提供Binder IPC机制。
[0004]为了实现虚拟机使用宿主机提供的Binder IPC机制,最直接的方案是直接将宿主机的Binder设备分配给虚拟机使用。然而由于Binder驱动实现的时候没有考虑多个系统同时使用的情况,这种方案并不可行。其主要原因在于原生的Binder驱动只允许存在一个Service Manager,所以这种方案下宿主机和虚拟机中的服务都只能注册到这个唯一的Service Manager。然而宿主机和虚拟机中运行的是同一套服务,相同的服务以相同的名字注册时必然会发生冲突,导致后运行的服务无法注册。另外,如果所有的服务都注册到同一个Service Manager,那么各个虚拟机中的客户端进程也无法区分哪些服务属于自己所在的虚拟机,哪些服务属于宿主机或其它的虚拟机。
[0005]如图1所示,Binder IPC机制包括Binder设备驱动、Binder支持库(未绘示)、Service Manager、服务和客户端等组件。其中服务是提供某种特定功能(如媒体播放)的进程,每个服务都有一个名字(如media, player)。服务启动之后将其名字注册到ServiceManager,后者负责保存服务名字与服务的对应关系。当客户端进程需要使用某个服务提供的功能时,它先向Service Manager发送请求获取服务名字对应的服务,之后便可以向服务发送请求使用其对应的功能。Binder设备驱动是Service Manager、服务和客户端三者之间通信的桥梁,这三者通过打开Binder设备(/dev/binder)并对其进行1/0操作(如open,ioctl, mmap等)来传递请求和响应。
[0006]在基于容器的Android虚拟化的实现方案中,虚拟机与宿主机共享同一个Linux内核。而Binder设备驱动属于内核的一部分,因此必须对Binder设备进行虚拟化。Binder设备的虚拟化的一种方案是在Linux内核中为宿主机以及每一个虚拟机都注册一个Binder设备,然后在每一个系统中均启动一个Service Manager,各个系统中的服务注册到其对应的Service Manager中,系统与系统之间互不影响。这种方案的优点是系统与系统之间完全隔离,不存在服务名字冲突的问题,但是也存在以下几个不足:
[0007]I)由于Binder设备驱动中使用了一些全局变量(如记录Service Manager进程信息的结构),为了创建多个Binder设备,需要为这些全局变量创建对应的副本,并且构建各个系统与这些副本之间的对应关系。这种方案要么需要对原有的Binder设备驱动进行大规模的修改,这不利于系统的稳定性;要么需要在内核中创建多个对等的Binder设备驱动程序,这样的设计又缺乏灵活性。
[0008]2)由于每个系统中的客户端都只能访问自身系统内部的Binder设备,因此这些客户端进程也只能使用该系统中运行的服务,这样无法实现系统之间服务的共享,即无法减少整个设备上运行的服务总数,不利于对设备的运行性能进行优化。
[0009]因此需要一种更加方便而且对性能影响较低的方法来解决Binder设备虚拟化以及服务共享的问题,为此本发明设计了一种虚拟机复用宿主机的Binder IPC机制的方法。

【发明内容】

[0010]本发明的目的在于提供一种Android虚拟化场景下复用Binder IPC机制的实现方法,这种方法应用在基于容器的Android系统虚拟化场景中,在几乎不修改Android原有代码的情况下实现Binder设备的虚拟化,并且实现服务共享的功能,为进一步优化Android虚拟化的性能提供了基础。
[0011]一种移动虚拟化场景中多Android系统复用Binder IPC机制的方法,所述多Android系统运行于单Linux内核环境中,所述多Android系统中其中一个运行于宿主机中,其余运行在虚拟机中,方法包括:
[0012]在宿主机中的Android系统中创建一个虚拟Binder设备驱动,并且使用该虚拟Binder设备驱动向Linux内核注册多个虚拟Binder设备,将这些虚拟Binder设备对应的设备文件分配给各个虚拟机;
[0013]虚拟机中Android系统的应用程序发出Binder设备的访问请求时,首先调用虚拟Binder设备驱动,虚拟Binder设备驱动对访问请求进行相应的拦截,并对访问请求中冲突的服务名进行过滤和修改处理,继而通过该虚拟Binder设备驱动将处理后得到的BinderIPC机制的使用请求转发给真实Binder设备驱动,实现虚拟机间接使用宿主机的BinderIPC机制。
[0014]本发明提供的多Android 系统复用 Binder IPC(Inter-Process Communication,进程间通信)机制的方法创建了一个虚拟Binder设备驱动,并创建了多个虚拟Binder设备分配给相应的多个虚拟机,最后通过与真实的Binder设备驱动相衔接,可以实现虚拟机复用宿主机的Binder IPC机制,这种方法具有很高的灵活性和可扩展性。同时在转发过程中通过对来自虚拟机的操作进行拦截,并且对特定使用的请求进行过滤和修改,解决虚拟机与宿主机运行同一种服务时存在的服务名冲突的问题。Binder设备驱动的函数,将应用程序(包括服务和客户端)对虚拟Binder设备的访问请求(如open、ioctl、mmap等)转发给真实的Binder设备驱动。
[0015]在转发应用程序对虚拟Binder设备的访问请求过程中,虚拟Binder设备驱动过滤出发送给Service Manager的注册服务(由服务的进程发起)和获取服务(由客户端的进程发起)的请求,并且在转发给真实Binder设备之前使用一个转换函数f修改这两种请求中的服务名字段。
[0016]其中虚拟Binder设备驱动采用自定义的驱动函数对需要拦截的访问请求进行拦截,对于不需要拦截的访问请求则直接使用真实Binder设备驱动中的函数。
[0017]对不需要拦截的操作直接调用真实的Binder设备驱动中的函数可以减少对内核的修改。
[0018]自定义的驱动函数包括过滤和修改命令,其中过滤和修改命令分析应用程序发送的ioctl命令并从中获取命令参数,从命令参数中获取Binder子命令,并判断各个Binder子命令是否需要修改,根据判断结果对Binder子命令进行处理。
[0019]其中,ioctl命令即为需要过滤的访问请求。在自定义的驱动函数中,需要自定义的函数只有conbinder_ioctl,该函数的实现分成两个部分,第一部分是过滤和修改命令,第二部分是将过滤和修改命令转交给真实Binder设备驱动中的binder_ioctl函数,第二部分直接调用binder_ioctl函数即可。过滤和修改命令首先从应用程序中过滤出ioctl命令,并对其进行处理,从而解决应用程序发出使用请求的服务名冲突问题。
[0020]其中判断各个Binder子命令是否需要修改的方法如下:
[0021]步骤1,判断Binder子命令是否为事务命令:是,则获取事务命令参数,并进入步骤2 ;否则,结束对该Binder子命令的处理;
[0022]步骤2,通过事务命令参数判断事务命令的目标服务是否为Service Manager,是则进入步骤3 ;否则结束对该Binder子命令的处理;
[0023]步骤3,判断事务命令的功能是否为注册服务、查询服务或者获取服务:是,则获取事务命令中的服务名,并修改该Binder子命令参数中的服务名;否则,结束对该Binder子命令的处理。
[0024]在步骤I中,当Binder子命令的命令号为BC_TRANSACTION时该Binder子命令为事务命令。在步骤3中,每个服务对应一个功能号,通过判断事务命令的功能号来判断该事务命令是否为注册服务、查询服务或者获取服务。
[0025]在步骤3中,在修改Binder子命令的服务名之前,还判断该服务的服务名是否存在于共享服务列表中:是,直接结束对该Binder子命令的处理;否则,修改服务名并结束对该Binder子命令的处理。
[0026]通过将宿主机中运行的特定服务的名字写入共享服务列表文件来设置该服务为共享服务。共享服务在宿主机中运行,被所有虚拟机共享。然后在虚拟Binder设备驱动的拦截和过滤规则中使用共享服务的列表作为白名单,使得虚拟机中对共享服务的请求能够穿透该虚拟设备驱动,实现虚拟机直接使用宿主机中运行的共享服务。
[0027]其中共享服务列表的建立方法为:在proc文件系统中创建一个共享服务列表文件,且在内核内存空间中分配一块区域用于存放文件内容,并将宿主机中运行的特定服务的服务名写入该共享服务列表文件中作为共享服务。
[0028]共享服务列表文件创建在proc文件系统中,并且在内核代码中创建该文件对应的读、写回调函数,当应用程序读取或写入服务名时,内核会调用对应的回调函数执行共享服务名的存储和读取。
[0029]其中在共享服务列表文件中,创建一棵红黑树用于索引该共享服务列表文件中存储的共享服务名。
[0030]红黑树具有较高的效率和较好的统计性能,可以用于快速查找该共享服务列表中的共享服务名。
[0031]修改冲突的服务名方法为,在拦截访问请求并进行过滤之后使用一个转换函数f来修改冲突的服务名。
[0032]其中,修改后的服务名中包含了修改前服务名以及发送该服务使用请求的来源信息。例如,虚拟机各自带有一个编号N,则修改后服务名中包含N的信息。
[0033]其中转换函数f满足以下所有条件:
[0034]a.修改后服务名不等于修改前服务名;
[0035]b.对于相同的修改前服务名和不同的虚拟机编号,修改后服务名不同;
[0036]c.对于不同的修改前服务名和相同的虚拟机编号,修改后服务名不同;
[0037]d.修改前服务名与修改后服务名长度相等。
[0038]满足以上条件的转换函数f保证来自虚拟机的服务名不同于宿主机的服务名,且不同虚拟机的相同服务具有不同服务名,相同虚拟机的不同服务也具有不同服务名,因此解决了服务名冲突的问题。由于请求的数据包格式已经确定,修改过的服务名也需要放回原来服务名的位置,而这个位置的长度是发送使用请求的应用程序确定的,因此修改后服务名与修改前服务名长度相等。
[0039]通过将虚拟机的根文件系统中的Binder设备与宿主机中的虚拟Binder设备绑定来分配虚拟Binder设备。
[0040]通过在mount命令中使用bind选项将这些设备与虚拟机根文件系统中的/dev/binder文件绑定,从而将各个Binder设备分配给各个虚拟机。虚拟机中的应用程序发出Binder设备使用请求时,内核将执行虚拟Binder设备驱动中的函数,对使用请求进行拦截,过滤和修改。
【专利附图】

【附图说明】
[0041]图1为现有技术Binder IPC机制工作原理图;
[0042]图2为本发明一个实施例的系统框架图;
[0043]图3为本发明当前实施例虚拟Binder设备驱动程序的结构图;
[0044]图4为本发明当前实施例虚拟Binder设备的功能原理图,图中不包括共享服务列表;
[0045]图5为本发明当前实施例处理一个Binder子命令的流程图;
[0046]图6为本发明当前实施例过滤和修改使用请求的主流程图。
【具体实施方式】
[0047]通过对Linux内核代码进行修改来实现本发明移动虚拟化场景中多Android系统复用Binder IPC机制的方法。在当前实施例中,修改的Linux内核版本为Linux3.9.4。[0048]如图2所示,Linux内核中具有真实的Binder设备驱动,本发明则在此基础上构建了虚拟Binder设备驱动,当虚拟机中的应用程序需要访问Binder设备时,应用程序向虚拟机中的Binder设备发出访问请求,贝U虚拟Binder设备驱动接收虚拟机应用程序对Binder设备的访问请求,并将这些访问请求进行拦截、过滤和修改处理,最终将处理过后得到的Binder IPC机制的使用请求转发给真实Binder设备驱动,实现虚拟机应用程序间接使用宿主机中的Binder IPC机制。虚拟Binder设备驱动在处理请求的过程中,会过滤出发送给Service Manager并且与服务名相关的Binder子命令,并且对这些Binder子命令中的服务名进行修改,以解决虚拟机直接使用真实Binder设备时存在的名字冲突的问题。
[0049]虚拟Binder设备驱动按照misc设备驱动的模型编写,代码存放在conbinder.c中。具体操作步骤如下:
[0050]首先,创建一个struct file_operations 类型的变量 conbinder_fops,这个结构体中的函数指针与虚拟Binder设备的各种操作一一对应。对于需要拦截的操作编写自定义的驱动函数,对于不需要拦截的操作则直接使用真实Binder设备驱动中的函数。驱动函数中各个函数的实现方式如下表所示:
[0051]
【权利要求】
1.一种移动虚拟化场景中多Android系统复用Binder IPC机制的方法,所述多Android系统运行于单Linux内核环境中,所述多Android系统中其中一个运行于宿主机中,其余运行在虚拟机中,其特征在于,方法包括: 在宿主机中的Android系统中创建一个虚拟Binder设备驱动,并且使用该虚拟Binder设备驱动向Linux内核注册多个虚拟Binder设备,将这些虚拟Binder设备对应的设备文件分配给各个虚拟机; 虚拟机中Android系统的应用程序发出Binder设备的访问请求时,首先调用虚拟Binder设备驱动,虚拟Binder设备驱动对访问请求进行相应的拦截,并对访问请求中冲突的服务名进行过滤和修改处理,继而通过该虚拟Binder设备驱动将处理后得到的BinderIPC机制的使用请求转发给真实Binder设备驱动,实现虚拟机间接使用宿主机的BinderIPC机制。
2.如权利要求1所述移动虚拟化场景中多Android系统复用BinderIPC机制的方法,其特征在于,其中虚拟Binder设备驱动采用自定义的驱动函数对需要拦截的访问请求进行拦截,对于不需要拦截的访问请求则直接使用真实Binder设备驱动中的函数。
3.如权利要求2所述移动虚拟化场景中多Android系统复用BinderIPC机制的方法,其特征在于,自定义的驱动函数包括过滤和修改命令,其中过滤和修改命令分析应用程序发送的ioctl命令并从中获取命令参数,从命令参数中获取Binder子命令,并判断各个Binder子命令是否需要修改,根据判断结果对Binder子命令进行处理。
4.如权利要求3所述移动虚拟化场景中多Android系统复用BinderIPC机制的方法,其特征在于,其中判断各个Binder子命令是否需要修改的方法如下: 步骤1,判断Binder子命令是否为事务命令:是,则获取事务命令参数,并进入步骤2 ;否则,结束对该Binder子命令的处理; 步骤2,通过事务命令参数判断事务命令的目标服务是否为Service Manager,是则进入步骤3 ;否则结束对该Binder子命令的处理; 步骤3,判断事务命令的功能是否为注册服务、查询服务或者获取服务:是,则获取事务命令中的服务名,并修改该Binder子命令参数中的服务名;否则,结束对该Binder子命令的处理。
5.如权利要求4所述移动虚拟化场景中多Android系统复用BinderIPC机制的方法,其特征在于,在步骤3中,在修改Binder子命令的服务名之前,还判断该服务的服务名是否存在于共享服务列表中:是,直接结束对该Binder子命令的处理;否则,修改服务名并结束对该Binder子命令的处理。
6.如权利要求5所述移动虚拟化场景中多Android系统复用BinderIPC机制的方法,其特征在于,其中共享服务列表的建立方法为:在proc文件系统中创建一个共享服务列表文件,且在内核内存空间中分配一块区域用于存放文件内容,并将宿主机中运行的特定服务的服务名写入该共享服务列表文件中作为共享服务。
7.如权利要求6所述移动虚拟化场景中多Android系统复用BinderIPC机制的方法,其特征在于,其中在共享服务列表文件中,创建一棵红黑树用于索引该共享服务列表文件中存储的共享服务名。
8.如权利要求1所述移动虚拟化场景中多Android系统复用BinderIPC机制的方法,其特征在于,修改冲突的服务名方法为,在拦截访问请求并进行过滤之后使用一个转换函数f来修改冲突的服务名。
9.如权利要求8所述移动虚拟化场景中多Android系统复用BinderIPC机制的方法,其特征在于,其中转换函数f满足以下所有条件: a.修改后服务名不等于修改前服务名; b.对于相同的修改前服务名和不同的虚拟机编号,修改后服务名不同; c.对于不同的修改前服务名和相同的虚拟机编号,修改后服务名不同; d.修改前服务名与修改后服务名长度相等。
10.如权利要求1所述移动虚拟化场景中多Android系统复用BinderIPC机制的方法,其特征在于,通过将虚拟机的根文件系统中的Binder设备文件与宿主机中的虚拟Binder设备文件绑 定来分配虚拟Binder设备。
【文档编号】G06F9/455GK103593225SQ201310526351
【公开日】2014年2月19日 申请日期:2013年10月30日 优先权日:2013年10月30日
【发明者】陈文智, 李川, 徐磊, 孙伟杰, 李国玺 申请人:浙江大学
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1