The Method OF Kill Given Process In Guest OS From VMM
康华 ：主要从事 Linux 操作系统内核、虚拟机、Linux 技术标准、计算机安全、软件测试等领域的研究与开发工作，曾就职 MII-HP 软件实验室 、瞬联软件公司/MOTOROLA，现就职于Lenovo研究院 。其所合写的Linux专栏见http://www.csdn.net/subject/linux/。 如果需要可以联系通过 kanghua151@msn.com （MSN）联系我.
Background
By now, we can monitor the Guest process running trace from VMM. Next goal is to do some further control on the given process of Guest OS from VMM.
What control we can do outside Guest? Too many! However, Kill a given Guest process from outside Guest is an obvious control and is useful at least : 1 terminating the suspicious guest process without need Guest know ;2 terminating the process in order to unfreeze deadlock for looping between two processes. So I implement “Kill feather” as first step.
Method
There at least four methods to do kill that I can think. I will give brief description below.
1 Preventing Guest OS‘s execution from switching to the target process from VMM. The straight way is that VMM load a invalid page directory address into guest’s Cr3 instead of the target process’s, as guest traps into VMM for loading CR3 register. (what will happen for guest os ?, I do not try )
2 Modifying the guest execution’s address(for Linux system ,which is stored in structure task_struture ‘s filed :thread.eip)to a invalid address ,So that when the target guest process is scheduled in , it’s execution will meet with an address fault, consequently, Guest OS will terminate it for execute fault. (it will cast a oops or segment fault )
The two methods above are belonging to brutal-force operation, which apply to process fault to kill process by Guest OS. The below I will introduce two graceful way to kill guest processes J
3 Injecting suicide code to the target process and modify the target process execution’s address (same as method 2) to suicide code entry----Such solution, you can look them as a special use for patching process at run-time from VMM----when given process resume, it will run suicide code to terminate itself.
Bye the way. 1 Injecting code into given process need alloc a memory region from guest physical memory, and then establish the mapping (need to modify the process’s page table) between this physical memory region and given process address space 2 suicide code involves a standard exit calling(that is enough).
4 Simulating a guest kill signal and send it to the target process from VMM.
As it is known, use can send a SIGKILL signal to given process in order to kill it. However, to do that, we must mention first Signal execute process, that is not as easy as you see. Actually, it can be divided into two separate steps: 1 generates a signal; 2 deliver a signal.
Ø Generate signal is that user or program take advantage of system calling (sys_signal) to set signal relative field in process descriptor (task_structure).
Ø Deliver a signal is that when given process is scheduled in, kernel will check it’s process descriptor whether signal relative field has been set. if set ,kernel will execute according signal handler for such signal.
We can do the first step—generate signal—from VMM by setting the signal relative field in the target process descriptor. And leave second step deliver signal to Guest OS as it does in usually way.
This is most graceful way to kill a process of Guest OS, its executing effect is nearly the same as you use “kill” command within Guest OS (for Linux System )----the given process will disappear immediately, as soon as it be schedule in.
Implement
Add a new ioctl entry (KVM_VM_KILL)in kvm_dev_ioctl for kill given process. The branch case for KVM_VM_KILL need do:
1 set signal field of pending field of given process descriptor
The signal to kill process is 9th signal, so we create signal structure and filled 9 kill signal like that set.sig[(9 - 1) / 32] |= 1UL << ((9 - 1) % 32);
2 set TIF_SIGPENDING flag of thread info field of given process descriptor
This is because the kernel checks the value of the TIF_SIGPENDING flag of the process before allowing the process to resume its execution in User Mode. So we need set it to 1 for telling kernel this process has pending signal waiting handle.
Limitation
The target process would be terminated only as it is scheduled in. So if it is not be scheduled in—it can be in block state--,it will not disappear in Guest OS ,even if we execute kill them from VMM. For this point ,execute kill command from Guest seem more reliable than from VMM， because it will first activate the target process in order to kill them immediately, However in VMM environment we cannot execute any guest routine in behave of guest (not in the same context), So we only can modify the guest data content ,only activate the target process.
HOWTO
Execute the command
./kvmctl –K <vmid> <gpid>