libvmi杂记

    libvmi是google的一个开源项目，利用memory introspection技术在Dom0中监视DomU的情况（进程，模块，内存....）。但是当运行module_list这个例子的时候，得到以下输出。

libvir: QEMU error : 未找到域: no domain with matching name 'Fedora_HVM'

    得到上面的输出是因为Fedora16，其自带KVM。而libvmi这个库对XEN和KVM都支持，而虚拟机Fedora_HVM这个虚拟机只存在于Xen Hypervisor中。因此上面的错误时KVM报出的，我们不用理会。因此，我在运行module_list本应得到Fedora_HVM DomU所加载的模块列表，但是却输出为空。

    为了找到为何输出为空的原因，我开始了我的取经之旅。首先是在google的讨论组（翻墙可入）中发帖子询问原因。下面是这个库作者的回话：

    There is an assumption about the linux memory layout in that example,
as mentioned in the comments.  You might need to check if your target
VM satisfies that assumption (e.g., looking at include/linux/module.h).

    言简意赅，大概说的就是，这不是我的错，我早在代码的注释中就写清楚了。代码中涉及到一种对内存布局的假设，实际上就是偏移量。想要运行代码成功得到结果，先看看你的module.h和我的事不是一样。

    于是我脸红的回来看module.h代码，找到module结构体定义的位置。

struct module
{
enum module_state state;


/* Member of list of modules */
struct list_head list;


/* Unique handle for this module */
char name[MODULE_NAME_LEN];
...
}

    发现存放模块名称的数组，距离module结构体的偏移量果真不是16，而是还需要加上一个枚举类型，也就是4个字节。于是将module_list.c修改如下：

if (VMI_OS_LINUX == vmi_get_ostype(vmi)){
            char *modname = NULL;
            if (VMI_PM_IA32E == vmi_get_page_mode(vmi)){ // 64-bit paging
                modname = vmi_read_str_va(vmi, next_module + 20, 0);
            }
...

    将next_module +　16改成了module + 20，结果还是没有输出。于是，打算gdb调试一下，但是明明在makefile中添加了-g选项，当时gdb module_list -tui却没有任何显示，所以手动gcc一下。由于本人是linxu菜鸟，所以gcc用的少，在gcc -I -l选项这里还折腾了一会。最后编译通过却报出以下错误。

./a.out: error while loading shared libraries: libvmi-0.6.so: cannot open shared object file: No such file or directory

    通过使用http://blog.csdn.net/qiek/article/details/537636这位仁兄的方法得以解决。

    最后得出结论，一个人很菜的话，还是可以学到很多东西的。