关闭

Device namespace简介 - 基于Kernel namespace的设备虚拟化

标签: linuxdevice
176人阅读 评论(0) 收藏 举报
分类:

转与:http://blog.csdn.net/jinzhuojun/article/details/43113195

在移动设备上,虚拟化的需求正在逐渐增加。其一,移动设备配置越来越高,一些高端配置已和桌面设备接近,这为虚拟化奠定了基础;其二,用户对于移动设备使用场景的多样性与日俱增。现在移动设备不仅用于娱乐日用,还用于工作;其三,安全与隐私问题日益凸显。移动设备上有更多的隐私信息,如各种账号,支付密码等,同时,各种病毒木马正在向移动设备迅速蔓延。这种背景下在一个隔离的环境中运行敏感软件是更加安全的做法;其四,多用户需求的出现。有时手机,尤其平板用户是多个,比如给小孩玩时就希望在一个特定的受限运行环境下。


桌面系统中的虚拟化技术已比较成熟,厂商也都提供了硬件支持,各种虚拟化解决方案也都使用广泛。而移动平台上,一方面由于计算能力相对有限,另一方面移动处理器对虚拟化的支持没有桌面系统中那么成熟完善。于是基于kernel namespace的container技术因其轻量级成为主要研究热点。而移动平台的一大特点就是各种硬件设备种类繁多,而kernel namespace之前主要用于服务器,服务器外设无论是种类还是数量都较少,显示器一般都可以省掉。而手机上各种sensor, camera, wifi, audio, display, radio, input, LED名目繁多。所以基于kernel namespace的话,一大难题就是解决设备的虚拟化。

在这样的背景下,device namespace在Columbia大学的研究性项目Cell(http://systems.cs.columbia.edu/projects/cells/)中提出,用于实现同一个手机上多个Android系统对设备的并发使用。它本质上是对kernel namespace的扩展。在该方案中,在kernel-level的虚拟化可分为三种方式:1) device driver wrapper, 如framebuffer. 2) namespace-aware subsystem, 如input. 3) namespace-aware device driver, 如binder。另外针对一些闭源的模块,比如RIL和wifi,需要用用户态的device namespace。简言之,就是整个系统启动时会起一个可信的最小初始化环境,称为root namespace。类似Xen里的dom0,它负责真正管理和切换其它虚拟系统,以及真正访问那些闭源模块。其它虚拟系统要访问时,通过IPC向root namespace申请。

随后,Cellrox以商业用途的license发布了device namespace的patch,作为Cellrox的Thinvisor技术一部分(https://github.com/Cellrox/devns-patches/wiki/DeviceNamespace)。Patch分三部分:1)framework主要包含了device namespace的框架,active device namespace的切换处理和对其它开放的API。2)traditional virtualization主要是为了隔离。使不同namespace的进程在操作设备时互不影响。比如binder, alarm, logger。3)context-aware virtualization主要是为了支持foreground-background模型。比如input, framebuffer, LED, backlight。在这个模型中,系统虽然存在多个虚拟系统,但只有一个是active的。所以一般情况下只有active namespace所在进程对设备的操作会生效,其它的不起作用。这儿又细分为statefull和stateless的device driver。对于stateless的好办,只要在处理时判断下是否active  device namespace,不是的话忽略。而statefull的话就得为每个device namespace保存虚拟状态。

下面以input系统为例来看看device namespace的基本框架和工作原理。首先,需要在已有kernel namespace的基础上加device namespace。具体地,在nsproxy结构中加了dev_namespace结构:

  1. struct nsproxy {  
  2.     ...  
  3.     struct dev_namespace *dev_ns;  
  4. };  
而nsproxy结构作为表示进程的结构task_struct的成员。也就是说,这样,对于一个进程,其nsproxy下的dev_ns代表了它所在的device namespace。nsproxy结构在同个namespace的进程间可以共享,但当这个nsproxy中的其中一个namespace被拷贝或取消共享,nsproxy就会被拷贝,变成所在进程私有。有点COW的意思。


dev_namespace这个核心结构如下:

  1. struct dev_namespace {  
  2.     bool active;  
  3.     ...  
  4.     pid_t init_pid;  
  5.     ...  
  6.     struct blocking_notifier_head notifiers;  
  7.     ...  
  8.     struct dev_ns_info *info[DEV_NS_DESC_MAX];  
  9. };  
其中active代表它是否是active的device namespace。init_pid是该device namespace下的init进程的pid。info是一个dev_ns_info结构的数组,每个元素代表该device namespace下的一个设备或子系统(为了简便下面统称设备)。notifiers是一个notifier_block链表,它把dev_ns_info结构里的成员nb串起来。它通过Linux notifier chains机制来让active device namespace切换时可以让每个注册设备调用处理函数。dev_ns_info代表在单个device namespace中的单个设备,它在device namespace中使用设备时创建(如果还没创建)。

  1. struct dev_ns_info {  
  2.    struct dev_namespace *dev_ns;  
  3.    struct list_head list;  
  4.    struct notifier_block nb;  
  5.    atomic_t count;  
  6. };  
其中的list元素用于把不同device namespace的同一设备串在表示该设备的结构dev_ns_desc上。

dev_namespace的初始值为init_dev_ns,它是代表init进程的device namespace。全局变量active_dev_ns指示现在active的device namespace。默认当然是init的device namespace。dev_ns_desc是系统中的全局数组,每个元素表示一个需要用device namespace的设备。
  1. struct dev_ns_desc {  
  2.    char *name;  
  3.    struct dev_ns_ops *ops;  
  4.    struct list_head head;  
  5. };  
  6. static struct dev_ns_desc dev_ns_desc[DEV_NS_DESC_MAX];  
其中的dev_ns_ops定义了device namespace framework调用具体device driver的接口。它的实现在device driver中。每个特定设备在初始化时会在dev_ns_desc里面注册一项。在driver-specific的xxx_dev_ns(如evdev_dev_ns)结构中要包含dev_ns_info结构。这样就把common的dev_ns_desc和具体device driver联系起来了。另外,device namespace的framework还通过DEFINE_DEV_NS_INFO定义了一系列的helper函数供driver使用。
  1. #define DEFINE_DEV_NS_INFO(X) \  
  2.      _dev_ns_id(X)     \  
  3.      _dev_ns_find(X)     \  
  4.      _dev_ns_get(X)     \  
  5.      _dev_ns_get_cur(X)      \  
  6.      _dev_ns_put(X)    
在每个需要device namespce的内核模块中需要定义该宏,如DEFINE_DEV_NS_INFO(alarm)。以evdev模块为例,DEFINE_DEV_NS_INFO(evdev)会生成以下内容:
  1. static int evdev_ns_id;   
  2.   
  3. static inline struct evdev_dev_ns *get_evdev_ns(struct dev_namespace *dev_ns)  
  4. {  
  5.      struct dev_ns_info *info;  
  6.      info = get_dev_ns_info(evdev_ns_id, dev_ns, 1, 1);  
  7.      return info ? container_of(info, struct evdev_dev_ns, dev_ns_info) : NULL;  
  8. }  
  9. static inline struct evdev_dev_ns *find_evdev_ns(struct dev_namespace *dev_ns)  
  10. {  
  11.      struct dev_ns_info *info;  
  12.      info = get_dev_ns_info(evdev_ns_id, dev_ns, 0, 0);  
  13.      return info ? container_of(info, struct evdev_dev_ns, dev_ns_info) : NULL;  
  14. }  
  15. static inline struct evdev_dev_ns *get_evdev_ns_cur(void)  
  16. {  
  17.      struct dev_ns_info *info;  
  18.      info = get_dev_ns_info_task(evdev_ns_id, current);  
  19.      return info ? container_of(info, struct evdev_ns, dev_ns_info) : NULL;  
  20. }  
  21. static inline void put_evdev_ns(struct evdev_dev_ns *evdev_ns)  
  22. {  
  23.      put_dev_ns_info(evdev_ns_id, &evdev_ns->dev_ns_info, 1);  
  24. }  
其中evdev_ns_id为dev_ns_desc数组和dev_namespace的info数组中对应该设备元素的index。它是在evdev初始化时evdev_init()函数中赋值的。
  1. ret = DEV_NS_REGISTER(evdev, "event dev");  
  2. if (ret < 0) {  
  3.     input_unregister_handler(&evdev_handler);  
  4.     return ret;  
  5. }  
本质上调用register_dev_ns_ops()在dev_ns_desc中注册了一个新设备,然后初始化。初始化时比较重要的一步是把模块相关的结构evdev_ns_ops注册到dev_ns_desc中去。这个接口的实现在evdev中,用于日后让device namespace的framework回调evdev子系统。
  1. static struct dev_ns_ops evdev_ns_ops = {  
  2.    .create = evdev_devns_create,  
  3.    .release = evdev_devns_release,  
  4. };  
前面提到过,dev_ns_desc中的一个元素代表一个设备。相当于设备的全局注册表。这里的注册过程是线性搜索第一个空的位置,返回这个位置的index作为evdev_ns_id。这里,设备还没有被真正使用,所以相应的dev_ns_info结构也没有创建,因此元素head中的链表为空。

然后,有那么一天,系统中的某一个进程打开了evdev子系统中的一个设备,然后evdev_open()-> evdev_ns_track_client(client)被调用。
  1. static int evdev_ns_track_client(struct evdev_client *client)  
  2. {  
  3.    struct evdev_dev_ns *evdev_ns;  
  4.    evdev_ns = get_evdev_ns_cur();  
  5.    ...  
  6.    client->evdev_ns = evdev_ns;  
  7.    ...  
  8.    list_add(&client->list, &evdev_ns->clients);  
  9.    ...  
  10. }  
这个函数中创建evdev_dev_ns结构。前面提到过,每个需要使用device namespace的设备都要定义这个xxx_dev_ns结构。它是deivce driver与device namespace framework的桥梁。evdev_dev_ns中包含了dev_ns_info结构。每次打开evdev设备会创建一个evdev_client对象。所有同一个device namespace下的evdev_client被串到代表该device namespace中evdev设备的结构evdev_dev_ns的成员clients中。

上面的get_evdev_ns_cur()依次调用get_dev_ns_info_task() -> get_dev_ns_info()。这个函数中会查打开设备进程所在device namespace中是否已注册该设备。有的话就直接返回,否则就调用new_dev_ns_info()新建。但这个dev_ns_info结构是被包在一个driver-specific的xxx_dev_ns结构中的。所以要调用之前注册的回调先初始化外面的结构,这里就是evdev_devns_create()。初始化完evdev_dev_ns后再把它里边的dev_ns_info返回,串到代表该设备的dev_ns_desc数组中去。看一下evdev_dev_ns_create(),其中创建driver-specific的device namespace结构evdev_dev_ns。然后注册notifier函数,它在切换active device namespace时会被回调。
  1. dev_ns_info->nb = evdev_ns_switch_notifier;  
  2. dev_ns_register_notify(dev_ns, &dev_ns_info->ns);  
这个notifier chain的结构如下:

考虑上面的数据结构,下面是一张总图说明它们之间的大体关系。这个例子中,其中有两个device namespace,考虑两个设备evdev和alarm。evdev在在两个device namespace都有使用,其中一个device namespace中有两个client。alarm只在一个device namespace中使用。



然后,当active device namespace切换时set_active_dev_ns()被调用。active device namespace的切换是通过/proc文件来通知kernel的。当然这仅是作demo之用,真正用时可以改为其它接口。在dev_namespace_init()中,创建/proc/dev_ns/active_ns_pid和/proc/dev_ns/ns_tag。它们的file_operations结构分别为active_ns_fileops和ns_tag_fileops。以active_ns_pid为例,当它被写时,触发proc_active_ns_write() -> dev_ns_proc_write() -> set_active_dev_ns(),接着它会调用先前注册的notifier函数。这里过程很直观,比如A namespace切到B namespace,先发DEV_NS_EVENT_DEACTIVATE事件到input driver通知A namespace切到后台,然后将active device namespace设为B,最后发DEV_NS_EVENT_ACTIVATE事件到input driver通知B namespace激活了。
  1. void set_active_dev_ns(struct dev_namespace *next_ns)  
  2. {  
  3.    ...  
  4.    (void) blocking_notifier_call_chain(&prev_ns->notifiers,  
  5.                        DEV_NS_EVENT_DEACTIVATE, prev_ns);  
  6.    (void) blocking_notifier_call_chain(&dev_ns_notifiers,  
  7.                        DEV_NS_EVENT_DEACTIVATE, prev_ns);  
  8.    ...  
  9.    next_ns->active = true;  
  10.    ...  
  11.    active_dev_ns = next_ns;  
  12.    ...  
  13.    (void) blocking_notifier_call_chain(&next_ns->notifiers,  
  14.                        DEV_NS_EVENT_ACTIVATE, next_ns);  
  15.    (void) blocking_notifier_call_chain(&dev_ns_notifiers,  
  16.                        DEV_NS_EVENT_ACTIVATE, next_ns);  
  17.    ...  
  18. }  
这里blocking_notifier_call_chain()本质上是调用之前注册的evdev_ns_swtich_callback(),该函数中先根据当前device namespace找到相应的evdev_dev_ns结构。这个evdev_dev_ns中的clients成员指示的链表串了该device namespace的所有设备使用会话,每个用evdev_client表示。前面图中有描述,evdev_client中为device namespace服务的成员有:
  1. struct evdev_dev_ns *evdev_ns;  
  2. struct list_head list;  
  3. bool grab;  
注意这里的grab是一个虚拟状态,记录着该会话如果在没有多个虚拟系统时是否独占设备,它只代表请求,不代表真正的grab状态,因为还要经过device namespace的逻辑。找到evdev_dev_ns结构后,通过clients成员遍历该device namespace中evdev所有打开的会话,如果处理的消息是DEV_NS_EVENT_ACTIVATE,说明该device namespace切到前台,则如果该会话之前设为独占,就调用evdev_grab()让其真正独占。如果处理的是DEV_NS_EVENT_DEACTIVATE,即该device namespace切到后台,如果当前会话是真正的独占会话,则调用evdev_ungrab()取消它的grab状态。到这里,把上面的流程总结一下:



有了这些信息后,就可以在读写input event时做一些namespace-aware的逻辑了。如在广播event事件时会检查device namespace,如果不是active的namespace就忽略。对于设备的写处理函数evdev_write()也是类似的。另外,在evdev_do_ioctl()中。对于非active的device namespace,很多时候就不作处理。在EVIOCGRAB的ioctl处理中,对于inactive的device namespace中的会话,将client->grab中的状态设为应该要设的状态,但不真正做事,而是如上节所说等到active device namespace切换时再做。

作为移动平台容器方案,device namespace还有需要扩展的地方,比如支持多个active的device namespace,但它提供了一种轻量级设备虚拟化的可行方案。其它设备虚拟化方案比如还有systemd中的multi-session(https://dvdhrm.wordpress.com/2013/08/25/sane-session-switching/),它可以免除对kernel的改动。具体使用可以按需求和设备类型结合多种方案。



0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:6722次
    • 积分:178
    • 等级:
    • 排名:千里之外
    • 原创:10篇
    • 转载:10篇
    • 译文:0篇
    • 评论:0条
    文章分类