[zz] 从VMM中终止GUEST OS中运行进程

从VMM中终止GUEST OS中运行进程

康华 ：主要从事 Linux 操作系统内核、虚拟机、Linux 技术标准、计算机安全、软件测试等领域的研究与开发工作，曾就职 MII-HP 软件实验室 、瞬联软件公司/MOTOROLA、LENOVO研究院 。其所合写的Linux专栏见http://www.csdn.net/subject/linux/。 如果需要可以联系通过 [email protected]（MSN）联系他. 

 

摘要: 本文在从VMM中识别GUEST OS中运行进程的基础上, 给出了从VMM中杀死GUEST OS中给定进程的方法并予以实现。

 

1. 背景介绍

       现在我们已经实现了在VMM监视Guest OS中运行进程这一任务。那么下一个目标将是如何控制Guest OS中的进程。最简单但又是最有用的控制需求就是终止Guest OS中的运行进程——这个功能可用于终止Guest OS中可疑进程,而Guest OS全然不知;或者可以用于解除循环进程死锁等种种目的。

2. 实现方法

 就实现终止GUEST OS进程这一目标，我所能想到的方法最少有4种,下来我简要介绍和对比一下各种方法的优缺点。

 1．在VMM中阻止Guest OS切换到目标进程，最直接的方法莫过于在切换时,不要将目标进程的页目录基地址载入CR3,而给其载入一个非法地址。（这样以来Guest OS会如何反映,我没有尝试）

 2．修改Guest OS的执行地址(Linux系统中该地址是存储在task_struture结构中域 :thread.eip中)为一个非法地址，这样以来当目标进程被调度后，其执行时将发生地址错误。不用说,Guest OS会终止它的执行。Linux下会在终止进程时给出oops或者段错误等提示。

上面两种方法都属于暴力操作——借助于进程错误而让GUEST OS杀死进程。下面我给出两个较为幽雅的方法终止Guest 进程。

 3．向目标进程空间中注射入一段自杀代码,并修改目标进程的执行地址(同方法2)到自杀代码处——这种方法可以将其看成是VMM给进程打patch的一个特例。当目标进程重新运行时，就会运行自杀代码终止自身。

   顺便说两点,1 注射代码到进程空间需要事先分配一段物理内存区以容纳patch代码，然后需要将这段内存影射到进程空间(需要修改进程页表)。2 自杀代码只需要含有标准的exit调用就可以了。

 4．从VMM中模拟Guest OS发送终止信号给目标进程.

   我们知道 SIGKILL信号可以终止进程,而深究其执行过程会发现信号执行分两个阶段: A 产生信号；B 传递信号。

n         产生信号是指用户或者程序利用系统调用sys_signal在目标进程的描述符(task_structure)中设置信号相关域,表示信号已到。

n         传递信号是指当进程被调度到时，内核会检查其是否有未处理信号(看那些信号相关域),如果有,则执行对应的信号处理程序。

   我们从VMM中执行第一步：产生信号，也就是给GUEST OS的目标进程的描述符中信号相关域置位。而第二步传递信号仍由Guest OS内核按原先方式执行，不去干预。这是最幽雅的一种终止进程的方法。其执行效果近似于在shell下发送kill命令来杀死进程——Guest OS的进程会立刻消失，只要其被调度到。

3. 具体实现

 

添加一个新的ioctl项KVM_VM_KILL,其处理过程需要做：

1.         设置进程描述符中pending域中的signal域。由于 SIGKILL是第9个信号，所以通过其下语句设置它set.sig[(9 - 1) / 32] |= 1UL << ((9 - 1) % 32)。

2.         设置进程描述符中thread info域中的TIF_SIGPENDING标识。这是因为内核会在恢复进程执行前检查该标志是否被设置。当其被设置时，内核才会去处理信号。

4. 限制

从VMM中终止目标进程的前提是：目标进程被调度。所以如果目标进程不被调度，比如在阻塞状态，那么就不能被立刻杀死。而我们知道在Guest 的shell中kill命令则可以杀死任何进程，不管它在什么状态下。这是应为kill命令能主动唤醒目标进程，以能迅速杀死它。而我们在VMM中无法唤醒GUEST OS的进程。（至少目前我没有想到如何从VMM上下文执行Guest OS 上下文中的唤醒例程）

5. 执行方法

./kvmctl -K <vmid>  <gpid>

 

6. 思考

        目前虚拟环境中，VMM和GUEST OS都自成体系，相互之间没有依赖关系。VMM的开发力求完全对GUEST OS透明，而GUEST OS的开发也不考虑VMM的存在。这样无疑是符合当前的现状的最佳方式：GUEST OS（无论是Linux也好，或者是WINDOWS也好）不需要做任何修改，拿来就可以用。但这种方式未必是最好的，可以想象VMM和GUEST OS之间如果能相互感知，那么应该能开发出更高效的虚拟系统，其性能和管理性都会有很大提高。鉴于这点，我想今后的VMM发展和操作系统发展将会考虑相互之间的信息共享或者互操作等问题，这也许是以后OS开发的新热点。