基于虚拟化的系统安全增强及显卡透传研究

1、基于虚拟化的系统安全增强及显卡透传研究侯建宁1，董贵山2，王银3，申娅4（1中国电子科技集团第三十研究所，四川 成都，610041；2中国电子科技集团第三十研究所，四川 成都，610041；3中国电子科技集团第三十研究所，四川 成都，610041；4成都卫士通信息产业股份有限公司，四川 成都，610041）摘要：本文着重于探讨系统虚拟化技术在终端安全领域的应用前景以及在推广应用中所面临的显卡性能问题的解决办法。针对个人终端操作系统安全问题，提出了一种基于系统虚拟化技术的操作系统安全增强模型，并基于KVM虚拟机深入研究了提高该模型下虚拟机显示性能的显卡透传技术的具体实现。实验结果证明显卡透传技术

2、能够突破虚拟机客户操作系统的显示性能瓶颈问题，使得客户机操作系统能够像真实操作系统一样满足图形显示与处理应用，对虚拟技术在终端安全领域的发展拓展了更广阔的空间。关键词：系统虚拟化技术；系统安全增强；KVM虚拟机；显卡透传；直接地址映射；PCI配置空间The Research on Virtualization-Based System Security Enhancements and Graphics Card Pass-ThroughHOU Jian-Ning1,DONG Gui-Shan2,WANG Yin3,SHEN Ya4(1.No.30 Institute of China Ele

3、ctronics Tecnology Group Corporation,Chendu,Sichuan 610041,China;2. No.30 Institute of China Electronics Tecnology Group Corporation,Chendu,Sichuan 610041,China;3.No.30 Institute of China Electronics Tecnology Group Corporation,Chendu,Sichuan 610041,China;4.Westone Information Industry Inc.Chendu,Si

4、chuan 610051,China)Abstract: This paper focuses on the prospect of system virtualization technology which applications in the terminal security field, and investigate the solution of the graphics performance problem when people promote the technology. For security issues of personal terminal operati

5、ng system, this paper propose a security Enhancements model based on the system virtualization technology on operating system, and in-depth study implementation of graphics Card pass-through technology to improve virtual machine performance based on this model on KVM virtual machine. Experimental re

6、sults show that graphics Card pass-through technology can breakthrough display performance bottlenecks of the virtual machine client operating system. This technology can make client operating system meet the graphics and processing applications as a real operating system, and can expand more space

7、for development of terminal security field.Key Words:System virtualization technology ;System Security Enhancements; KVM virtual machine;Graphics Card pass-through; Direct address mapping; PCI Configuration Space概述虚拟化技术存在和发展已达四十多年的时间了，近年来，随着研究的深入，系统虚拟化技术已在X86体系架构上获得了很好的发展，在企业计算、灾难恢复、分布式计算、桌面虚拟化领域均得到

8、了广泛应用1。在信息安全领域，因系统虚拟化层介于硬件平台与用户操作系统之间，其特有的客户机操作系统监控和隔离作用，使得系统虚拟化技术不仅仅可以用于服务器端实现资源整合与管理功能，也可以增强以操作系统安全为核心的用户终端系统的安全性，因此虚拟技术在信息安全领域也备受关注。在国内，系统虚拟技术在信息安全领域的技术研究已经开展比较多，目前在硬件资源访问控制、操作系统恶意行为监控、隐藏进程检测等方面已有相关的研究23。主要的思路是在虚拟机监控器（VMM，Virtual Machine Monitor）中构筑一系列的安全防护措施，强化对客户机操作系统的安全监控与管理，但此类技术的应用研究目前还处于起步阶

9、段，尚无完整的应用实现方案。本文借鉴国内外当前相关技术研究成果，结合个人终端操作系统安全防护实际需求，提出了一种适用于个人终端计算机、基于虚拟技术的操作系统安全增强模型。根据该模型在终端安全领域应用推广中将会面临的显卡性能问题，提出了一种提高虚拟机显示性能的显卡透传技术，并基于KVM虚拟机深入研究了显卡透传技术的具体实现。显卡透传技术的突破，能够很好的解决客户机操作系统的易用性难题，对促进系统虚拟化技术在终端操作系统安全增强领域的推广应用起着重要的作用。操作系统安全增强模型在个人终端操作系统安全增强方面，需要做到既能维护系统的安全性，又需要保证系统的易用性和高效性。根据这个需求特点，我们通过改

10、造现有虚拟机体系结构，提出了个人终端操作系统安全增强模型。传统系统虚拟化体系模型如图1所示，改造后的操作系统安全增强模型体系结构如图2所示。在基于虚拟技术的个人终端操作系统安全增强模型上，一台PC机只运行一个独立的虚拟客户机操作系统，该系统对于用户来说就是普通的用户操作系统。虚拟机监控器则成为安全监控器，负责根据访问策略隔离与控制客户机操作系统对硬件资源的访问权限，可以根据安全性需要将不存在安全隐患的硬件（显卡、声卡、键盘、鼠标等）透传给客户机操作系统直接控制，对存在安全隐患的硬件资源（如网卡、USB端口）进行虚拟，在虚拟层实施访问过滤等检测措施确保访问安全；同时通过在虚拟化层实现进一步的恶意

11、行为检测、隐藏进程检测等安全模块对客户机操作系统各种恶意行为进行监控。相比于通用虚拟机体系结构4，这种安全模型中虚拟机监控器主要职能不再是多虚拟环境的调度与切换，而转变为对单一虚拟机的安全监视功能，简化了传统系统虚拟化体系结构的复杂性，增强了操作系统安全性控制功能。图1：传统系统虚拟化体系模型图2：基于虚拟化技术的操作系统安全增强模型这种安全模型的推广应用，要求虚拟机下的客户机操作系统应具备与运行于真实主机上的操作系统相同或相近的性能与通用性，否则终端用户是无法接受因安全增强而带来的性能或易用性方面的损失的。自2005年， Intel和AMD公司分别发布了支持VT（Virtualization

12、 Technology）技术的CPU以来，基于支持VT技术的CPU虚拟化技术已经让虚拟机处理性能产生了质的提升，能够达到真实主机性能的95%以上，CPU处理性能已经不再是虚拟化技术在终端安全领域发展的绊脚石。而显卡显示性能问题则成为当前虚拟化技术在终端安全领域发展的关键问题，当前国外主流的虚拟机软件都没能很好的解决好显卡虚拟化问题，虚拟机的图形显示处理能力只相当于当年的386时代的水平，这使得虚拟机中的客户机操作系统不能够运行一些对图形处理能力要求高的应用，这种安全模型的进一步发展存在着较大的障碍。下面将基于KVM虚拟机研究实现提升客户机操作系统显示性能的具体实现方法，本文的研究主要是基于KV

13、M虚拟机进行的，但相关技术原理具有普适性，也可在其他开源虚拟机上得到实现。KVM虚拟机当前，主流的商业虚拟机有VMware和VirutalPC，开源虚拟机有Xen、Qemu、Bochs、KVM等。KVM5是Kernel-based Virtual Machine的简称，是一个基于Linux内核，依赖CPU硬件虚拟化技术（如Intel 或AMD VT技术)的的开源系统虚拟化模块。KVM虚拟机的体系架构如图3所示，VMM虚拟机监控器借助于Linux操作系统的内核实现。图3：KVM虚拟机原理图KVM虚拟机支持PCI透传技术（PCI passthrough），可以实现将PCI硬件资源直接映射到虚拟机的

14、客户操作系统中，客户操作系统可以直接驱动真实的标准PCI物理设备以获得高速物理资源访问。但KVM虚拟机支持PCI透传技术还必须依赖于硬件平台支持Intel 或AMD的VT-d/IOMMU技术。VT-d/IOMMU技术在服务器虚拟化中对I/O虚拟化具有重要作用，但在终端用户的操作系统安全增强模型中却并不重要，此外，由于VT-d/IOMMU技术主要面向服务器设计，普通PC机上支持不多。因此，在基于KVM虚拟机的操作系统安全加固模型中实现显卡透传主要有两方面的研究工作：一方面是研究在不支持VT-d/IOMMU技术的硬件平台上实现PCI透传的方法；另一方面是实现对显卡这种特殊的PCI设备在虚拟机中的直

15、接分配。直接地址映射技术基本原理在虚拟机中实现PCI透传，需要处理好4方面的问题：PCI配置空间映射；PCI内存及I/O资源映射；PCI IRQ中断映射；DMA（直接内存访问）处理；通常情况下，对于标准PCI设备，前三个方面的处理均可以通过虚拟机相应的软件映射机制实现，而对虚拟给客户机操作系统的物理硬件DMA的处理则是现有的虚拟方式下难以用软件实现的，这与DMA本身的技术机制有关。DMA是外设与系统进行高速数据传输的技术，外设可以不经过CPU直接进行内存读写访问，高效传输数据。在DMA传输时驱动需要申请一个可被DMA访问的地址空间，然后告诉外设可进行DMA传输的内存物理地址。这种方式在物理主机

16、上没有任何问题，操作系统会保证分配给驱动的地址空间独立性。但在虚拟机上，因采用影子页表机制实现多个客户机物理地址到主机物理地址的映射，驱动从系统中获取的物理地址实际上是经过虚拟机转换后的客户机物理地址（GPA），并非对应真实的主机物理地址（HPA）。如果外设直接存取该地址的数据必然导致系统崩溃或造成安全隐患。Intel 的VT-d和AMD的IOMMU技术则是从硬件层面解决DMA处理问题的有效办法。与CPU上的Intel VT-x技术一样，VT-d（ Virtualization Technology for Directed I/O）技术是一种基于北桥（North Bridge）芯片的硬件辅助

17、虚拟化技术，通过在北桥中内置提供DMA虚拟化和IRQ虚拟化硬件，实现了新型的I/O虚拟化方式。运用VT-d技术，虚拟机得以使用直接I/O设备分配方式或者I/O设备共享方式来实现PCI设备透传，从而大大提升了虚拟化的I/O性能。AMD与之类似的技术称之为SVM IOMMU。Intel 的VT-d和AMD的IOMMU技术支持DMA虚拟化的主要原理是由硬件维护一张DMA重映射表，当外设对某个物理地址进行DMA操作时，自动查找映射表，将操作地址映射为虚拟机内GPA对应的真实HPA，以避免错误的内存地址操作。该技术具有通用性，可以同时支持多个虚拟机同时进行物理设备透传，且互相不影响，但需要有主板芯片组支

18、持才能使用，对硬件依赖性较高,KVM虚拟机已支持基于VT-d技术的PCI设备透传6。但在终端操作系统安全加固模型中，我们不需要对多虚拟机同时进行物理设备透传，因此，并不需要维护一张1对多的DMA重映射表，我们只需要处理好GPA等于HPA的问题即可有效确保硬件对DMA地址处理的合法性，使得虚拟机对物理硬件具有与真实主机一致的效果。本文针对DMA处理问题，提出了虚拟机与物理主机直接地址映射技术的解决方案。实现方式直接地址映射是通过将真实系统中低地址内存直接分配给虚拟机使用，直接让虚拟机的GPA对应主机HPA的技术。直接地址映射技术可以不需要任何硬件辅助，做到DMA访问的物理地址内存与主机一致。但该

19、技术的缺点是，一个主机系统中只能同时运行一个进行物理设备透传的虚拟机，多个虚拟机同时进行物理设备透传则会造成地址冲突。KVM是基于Linux操作系统运行的。实现直接地址映射的先决条件是需要Linux操作系统在启动时将低地址内存空间预留出来。为保证体系兼容，X86架构下的低1M内存空间在操作系统初始化前就已预留给实模式中断向量表、BIOS数据、显存等使用，我们不能在Linux上预留这部分空间，只能从1M以上的空间开始预留。对于2.6内核，有一个PHYSICAL_START变量设置系统启动时内核加载地址，缺省指向地址0 x100000（1M）处，我们可以修改为更大的值让系统在启动时空出1M到PHY

20、SICAL_START地址之间的内存空间，然后将这部分空间标记为预留，以避免操作系统启动后占用这部分空间7。从操作系统层面预留的这部分空间是无法直接在应用层直接使用的，目前我们通过Linux下/dev/mem设备文件直接将预留内存映射到应用层QEMU为虚拟机分配的内存空间中，映射时需注意确保HPA与GPA的对应。而对于虚拟机的其它内存空间，无需与物理地址对应关系，依然采用影子页表机制将虚拟机内存地址映射为Linux分配给QEMU的内存空间中。具体映射关系见图4。从图中可以看出，在成功实现内存映射后，客户机操作系统所使用的内存实际对应到了主机的真实内存部分，映射时确保了地址的一一对应。而虚拟机前

21、640k内存空间均由QEMU进行虚拟，占用的是Linux操作系统的内存空间。考虑到运行态主机的VGABIOS内存空间存储的是被修改过的BIOS代码，因此虚拟机中VGABIOS内存空间均由QEMU进行虚拟，也占用的是Linux操作系统的内存空间。图4：直接地址映射下虚拟机内存与物理内存的对应关系显卡直接分配从KVM虚拟机结构中可以看出，如果虚拟机需要访问QEMU模拟出的外设，则需要通过多次处理，才能够将数据真正传递给真实硬件设备处理，这对于普通低速接口的硬件外设访问来说虚拟化处理开销还容易接受，但对于显卡虚拟化来说性能问题将显得尤其突出。因此，采用显卡直接分配技术将物理显卡单独分配给一个虚拟机独

22、占访问，使虚拟机上的客户端操作系统直接驱动物理显卡，进行MMIO访问和DMA操作，是一个在虚拟环境中获得高质量图形显示效果的有效解决方案。图5是显卡直接分配技术与QEMU直接虚拟外设的处理对比。从图中可以看出，显卡直接分配给虚拟机的客户操作系统还可以使得客户机操作系统充分利用物理显卡原始驱动实现显卡效能的最大化发挥。图5：显卡直接分配与QEMU虚拟外设技术对比开源的KVM虚拟机目前已经支持对标准PCI设备的直接透传（需要硬件具备I/O虚拟化能力，即需要硬件对VT-d或IOMMU技术的支持），但还没能够支持显卡的直接透传。主要有两方面原因：一个是因历史遗留问题，X86体系架构下的显卡设备为实现兼

23、容，留下了一些不同于标准PCI设备的内存和I/O端口；另一个是因显卡其自身高速处理需要，各显卡厂商可能会有一些特别的设计（如独立显存和共享显存的设计、特殊访问接口等），针对显卡不能完全像标准PCI设备一样简单的实现设备直接透传。这里我们借鉴XEN虚拟机下基于VT-d技术的显卡直接分配技术8，解决了KVM基于直接地址映射技术的显卡设备直接分配难题。在KVM中实现显卡直接分配，需要解决好显卡在虚拟机总线中的注册、PCI配置空间虚拟、显卡资源（显存及I/O地址）映射、VGABIOS调用、DMA映射等一系列问题。本文将针对以上问题展开研究。显卡在KVM虚拟机中的注册KVM使用QEMU用户态进程虚拟外设

24、，显卡如果在虚拟机中使用必须首先在QEMU中注册为一个称为pci-assign的特殊qdev虚拟设备。pci-assign虚拟设备是QEMU中专门为PCI透传定义的虚拟设备类型，每一个被透传到虚拟机中的PCI设备都会被注册为一个pci-assign虚拟设备，客户机操作系统对该虚拟设备进行的MMIO访问等操作都被直接转发到对应的真实物理设备上。该功能的实现已经在QEMU-KVM源代码中包含，只需要在启动KVM时通过命令行指定要映射的PCI设备BDF号（总线号、设备号、功能号）即可实现将该设备注册到虚拟机中。但是做为显卡设备，仅仅注册为pci-assign虚拟设备并不能完全将显卡启用，虚拟机中能够

25、从PCI资源中看到该显卡，但是显卡依然无法工作，还需要进一步完成后续的工作。显卡专用总线的注册因为其性能需要，X86架构下大部分平台都将物理显卡挂接在独立的一根PCI总线（总线1或总线2）上，有些厂商的显卡驱动会对显卡BDF号进行检测，如果显卡在物理主机上的BDF号与虚拟机中注册的BDF号不一致，将无法正确驱动显卡（笔者试验用的NVIDIA Geforce G205M显卡就存在这个问题）。因此，为确保显卡直接分配技术在各类显卡中能够通用，需要在注册显卡到虚拟机中时确保显卡在虚拟机中的BDF号与真实机器的BDF号保持一致。QEMU中缺省只虚拟了一条PCI总线（总线0），虚拟的磁盘控制器、CD-R

26、OM驱动器、网卡、显卡、声卡等设备都注册在这条总线上。为满足显卡直接分配的需要，我们要修改QEMU源码多注册两条PCI总线。这里我们利用QEMU中已实现的虚拟PCI桥设备，在虚拟机的系统总线初始化时注册2个QEMU DEC 21154 虚拟PCI桥设备，创建了总线1和总线2。然后我们修改QEMU注册PCI设备的实现方式，指定将透传显卡设备按照其真实主机上BDF相同的总线号、设备号、功能号进行一一对应的注册。这样就实现了显卡在虚拟机中与在真实主机上具有相同的BDF，以使得显卡驱动能够直接驱动显卡。显卡资源直接映射历史遗留资源映射自第一台IBM PC问世以后，显卡经历了MDA, Mono Herc

27、ults, CGA, EGA, VGA, XGA, SVGA等等标准，总线也由ISA, EISA, VESA, PCI, AGP直到现在的PCIE，前前后后共约30年的进程。虽然好多硬件都渐渐湮没在历史的洪流中，但是由于兼容性需要，一些内存或I/O端口还是作为历史遗留资源在X86硬件体系中保留了下来。在Intel制定PCI总线标准时，在PCI空间保留了从0开始连续1MB的Memory空间和从0开始连续64KB的I/O空间，其中给显卡预留的空间见表1。表1：PCI显卡历史遗留资源类型地址范围用途内存空间0 xA0000 0 xAFFFFVGA显示缓冲区0 xB0000 0 xB7FFFMDA或H

28、ercults单显卡显示缓冲区0 xB8000 0 xBFFFFCGA/EGA显示缓冲区0 xC0000 0 xCFFFFVGA BIOS 专用I/O 空间0 x3B00 x3DF显卡控制寄存器I/O空间在PC机启动的时候，BIOS程序会扫描整个PCI空间，发现有PCI显卡时，会使能它的Mem访问和I/O访问，同时会配置它的内存空间和I/O空间。但是上面提到的那两块保留的内存空间和I/O空间是不需要作专门配置的，PCI显卡可以直接响应落在这两段空间上的PCI访问请求。进行显卡透传时必须将物理主机特殊的预留内存和I/O地址空间直接映射到虚拟机对应的地址空间中，以保证显卡初始显示。对于0 xA00

29、00 0 xBFFFF内存空间向虚拟机的映射，我们借助Linux下特有的/dev/mem设备实现，通过/dev/mem设备可以访问到整个PC的全部物理内存。我们修改QEMU源代码，在分配了虚拟机的内存后（得到一个应用层地址空间的虚地址），直接打开/dev/mem设备，将地址0 xA0000到0 xBFFFF内存使用mmap方式直接映射到QEMU虚拟机的内存空间对应偏移地址处。对于I/O端口0 x3B00 x3DF的映射，可直接向QEMU中注册IO读写函数，该函数从应用层空间上转发对应的读写操作到真实主机的I/O端口上。显卡资源映射除历史遗留资源外，各种显卡还有其特有的内存和I/O资源，需要将这

30、些资源都映射进虚拟机中。Linux下的SYSFS系统提供了一种从应用层访问内核资源的简单途径。所有的PCI设备资源在系统初始化时都自动映射成/sys/bus/pci目录下的文件，应用层如果访问这些资源可直接打开文件将其mmap到内存中，对映射内存的读写操作都会传送到PCI设备的内存空间中。在注册物理显卡到虚拟机时，需要将对应的显卡资源也映射到虚拟机的地址空间中去。显卡的PCI配置空间在实现显卡直接分配时，最重要的是显卡的PCI配置空间虚拟化。PCI配置空间是用来动态配置PCI设备资源占用的一组寄存器，每个PCI设备都有自己独立的配置空间，在系统初始化时，由BIOS（也可在操作系统中配置）根据一

31、定的算法分配PCI设备所占有的资源，并将资源信息写入PCI设备配置空间。PCI总线规范9定义的配置空间总长度为256个字节，配置信息按一定的顺序和大小依次存放。前64个字节的配置空间称为配置头，对于所有的设备都一样，配置头的主要功能是用来识别设备、定义主机访问PCI卡的方式（I/O访问或者存储器访问，还有中断信息）。其余的192个字节称为本地配置空间，主要定义卡上中断、I/O端口资源、内存基地址及范围等信息。PCI配置空间中的基地址寄存器BAR（Base Address Registers）就是用于配置PCI设备在系统中占用的I/O及内存地址及范围的寄存器。对于普通PCI设备，可以直接虚拟PC

32、I配置空间，由KVM虚拟机的BIOS在启动时重新配置该空间中的BAR和中断号等信息。但有些厂商的显卡则必须实现虚拟机里基地址寄存器值等于物理设备上基地址寄存器的值（VBAR=PBAR），原厂驱动才能够正确驱动显卡。因此，为保证显卡透传功能的通用性，我们针对显卡都采用VBAR=PBAR的映射方式。这需要为显卡透传专门修改虚拟机BIOS，使得其在开机初始化时针对显卡保留其与PBAR一致的虚拟机IO及内存资源。针对显卡的透传修改QEMU代码，在注册pci-assign虚拟设备时将设备真实PCI配置空间内容完整复制到虚拟配置空间。然后修改SeaBIOS（KVM虚拟机使用的BIOS）中PCI设备探测与资

33、源分配部分的代码，在虚拟机SeaBIOS设置显卡各配置寄存器时，首先读取虚拟配置空间中的真实设备配置信息，优先为显卡分配虚拟机 “硬件”资源，确保被透传的显卡与真实显卡保持一致的基地址寄存器配置信息。对于显卡中断等配置则可以根据需要由虚拟机进行映射转换，中断号的虚拟不影响显卡透传。VGA BIOS显卡也具有与主板上一样的基本输入输出系统（BIOS），称为VGA BIOS。系统加电启动时，主板BIOS会寻找到显卡，复制显卡中的VGA BIOS到系统预留VGA BIOS专用内存空间中（地址0 xC0000 0 xCFFFF），并调用VGA BIOS初始化显卡。每种显卡都有自己专用的VGA BIOS

34、，存储在显卡ROM存储区或主板BIOS中。如果需要在虚拟机中初始化显卡，则必须在虚拟机BIOS中重新调用VGA BIOS。因此，我们需要提取VGA BIOS文件给虚拟机，由虚拟机启动时将该VGA BIOS代码复制到VGA BIOS专用内存空间中执行显卡的初始化。显卡VGA BIOS的提取有很多种方式，具体如何提取需要视主板或显卡情况而定。大部分显卡的VGA BIOS可以用工具从内存中提取（如AFLASH、GPU-Z等）。但有些显卡，如NVIDIA显卡，在VGA BIOS执行时会自动修改自己在内存中的部分代码，直接提取到的VGA BIOS无法用来初始化显卡。笔记本电脑集成的显卡通常都会将显卡BI

35、OS集成到主板BIOS中，我们可以通过提取主板BIOS，分析出显卡BIOS存储位置，提取对应的VGA BIOS。DMA映射显卡的DMA映射问题，采用直接地址映射技术技术解决，通过修改Linux操作系统内核，预留从0 x0 x100000（1M）地址开始的物理内存空间，直接映射给客户机操作系统使用，解决了客户机操作系统下直接对显卡DMA的处理。小结虚拟机显卡透传技术解决了虚拟客户机操作系统图形显示效果差的难题。在终端安全领域，显卡透传技术通过客户机操作系统直接驱动物理显卡获得高质量显示效果，使得虚拟机中的客户操作系统具有更普遍的适应性，能够满足普通用户的使用需求，为基于全系统虚拟化技术的操作系统

36、安全增强、进程控制、病毒防护等技术的研究成果更进一步的拓展了实用空间。由于时间和能力所限，本技术的研究成果主要适用于当前主流的独立显存的显卡，对于一些特殊显卡或共享显存的集成显卡还会有些特殊处理，这里不再详述。通过在华硕K40IP笔记本电脑（支持VT-x,不支持VT-d）上验证，主机向客户机操作系统直接分配NVIDIA G205M显卡，并安装原厂驱动进行测试，测试证明虚拟机操作系统的显示效果得到质的提升，获得了和主机显示完全接近的效果。参考文献1董耀祖，周正伟.基于X86架构的系统虚拟机技术与应用J.计算机工程，2006 Vol. 32 (13): 71-732马文琦. 基于虚拟化的多域安全框

37、架及其关键技术研究D. 湖南长沙：国防科学技术大学研究生院，20083杜 海，陈 榕. 基于完全虚拟化的进程监控方法J.计算机工程,2009Vol.35(8):88-904英特尔开源软件技术中心，复旦大学并行处理研究所著.系统虚拟化原理与实现M.北京：清华大学出版社，20095 KVM-kernel-based Virtual MachineDB/OL./page/Main_Page,20106How to assign devices with VT-d in KVMDB/OL./page/How_to_assign_devices_with_VT-d_in_KVM ,20107河秦，王洪涛

38、.Linux2.6内核标准教程M.北京：人民邮电出版社,20088Beng Heng Ng, Billy Lau, Atul Prakash. Direct Access to Graphics Card Leveraging VT-d Technical ReportR. HYPERLINK /bengheng/pubs/vgapt_techreport.pdf /bengheng/pubs/vgapt_techreport.pdf ,July 20, 20099PCI Local Bus Specification Revision 3.0. PCI Special Interest Gr

39、oup ,February 3,2004声明：本课题无任何基金或项目支持作者简介：侯建宁，1978，男，工程师，学士，主研方向：信息安全、虚拟化技术、网络安全监管技术，手机贵山，高级工程师，博士，手机银，工程师，学士申娅，工程师，学士附录资料：不需要的可以自行删除 busybox详解制作根文件系统详解制作根文件系统 一、FHS（Filesystem Hierarchy Standard）标准介绍当我们在linux下输入ls / 的时候，见到的目录结构以及这些目录下的内容都大同小异，这是因为所有的linux发行版在对根文件系统布局上都遵循FHS

40、标准的建议规定。该标准规定了根目录下各个子目录的名称及其存放的内容：目录名存放的内容/bin必备的用户命令，例如ls、cp等/sbin必备的系统管理员命令，例如ifconfig、reboot等/dev设备文件，例如mtdblock0、tty1等/etc系统配置文件，包括启动文件，例如inittab等/lib必要的链接库，例如C链接库、内核模块/home普通用户主目录/rootroot用户主目录/usr/bin非必备的用户程序，例如find、du等/usr/sbin非必备的管理员程序，例如chroot、inetd等/usr/lib库文件/var守护程序和工具程序所存放的可变，例如日志文件/pro

41、c用来提供内核与进程信息的虚拟文件系统，由内核自动生成目录下的内容/sys用来提供内核与设备信息的虚拟文件系统，由内核自动生成目录下的内容/mnt文件系统挂接点，用于临时安装文件系统/tmp临时性的文件，重启后将自动清除制作根文件系统就是要建立以上的目录，并在其中建立完整目录内容。其过程大体包括：编译安装busybox，生成/bin、/sbin、/usr/bin、/usr/sbin目录 利用交叉编译工具链，构建/lib目录 手工构建/etc目录 手工构建最简化的/dev目录 创建其它空目录 配置系统自动生成/proc目录 利用udev构建完整的/dev目录 制作根文件系统的jffs2映像文件

42、下面就来详细介绍这个过程。二、编译安装busybox，生成/bin、/sbin、/usr/bin、/usr/sbin目录这些目录下存储的主要是常用命令的二进制文件。如果要自己编写这几百个常用命令的源程序，my god， 这简直是一个噩梦！好在我们有嵌入式Linux系统的瑞士军刀busybox，事情就简单很多。1、从 HYPERLINK / / 下载busybox-1.7.0.tar.bz22、tar xjvf busybox-1.7.0.tar.bz2解包3、修改Makefile文件175 ARCH ?= arm176 CROSS_COMPILE ?= arm-linux- 4、make me

43、nuconfig配置busyboxbusybox配置主要分两部分。第一部分是Busybox Settings，主要编译和安装busybox的一些选项。这里主要需要配置：1）、Build Options - Build BusyBox as a static binary (no shared libs)，表示编译busybox时，是否静态链接C库。我们选择动态链接C库。2）、Installation Options - Applets links (as soft-links) - (X) as soft-links，表示安装busybox时，将各个命令安装为指向busybox的软链接还是硬链

44、接。我们选择软链接。3）、Installation Options - (/work/nfs_root/fs_mini3) BusyBox installation prefix，表示busybox的安装位置。我们选择/work/nfs_root/fs_mini34）Busybox Library Tuning。保留Command line editing以支持命令行编辑；保留History size以支持记忆历史命令；选中Tab completion和Username completion以支持命令自动补全 第二部分是Applets，他将busybox的支持的几百个命令分门别类。我们只要在各

45、个门类下选择想要的命令即可。这里我们基本保持默认设置。1）选中Networking Utilities - httpd下的Enable -u option，以启用http服务器的功能allows the server to run as a specific user5、编译busyboxmake6、安装busyboxmake install安装完成后，可以看到在/work/nfs_root/fs_mini3目录下生成了binsbinusr/binusr/sbin目录，其下包含了我们常用的命令，这些命令都是指向bin/busybox的软链接，而busybox本身的大小不到800K：dennis

46、dennis-desktop:/work/nfs_root/fs_mini3$ lsbin linuxrc sbin usrdennisdennis-desktop:/work/nfs_root/fs_mini3$ ls -l bintotal 740lrwxrwxrwx 1 dennis dennis 7 2010-04-03 23:57 addgroup - busyboxlrwxrwxrwx 1 dennis dennis 7 2010-04-03 23:57 adduser - busyboxlrwxrwxrwx 1 dennis dennis 7 2010-04-03 23:57 a

47、sh - busybox-rwxr-xr-x 1 dennis dennis 749632 2010-04-03 23:57 busyboxlrwxrwxrwx 1 dennis dennis 7 2010-04-03 23:57 cat busybox 而普通PC机上的ls命令就有差不多80K的大小： dennisdennis-desktop:/work/nfs_root/fs_mini3$ ls -l /bin/ls-rwxr-xr-x 1 root root 78004 2007-09-29 20:51 /bin/ls busybox以它娇小的身躯容纳了数以百计的命令代码，实在是让人佩服

48、不已，其不愧嵌入式系统瑞士军刀之美誉。据说，busybox的作者身患绝症，这更让人钦佩GNU开源软件的作者们。 三、利用交叉编译工具链，构建/lib目录 光有应用程序（命令）是不够的，因为应用程序本身需要使用C库的库函数，因此还必需制作for ARM的C库，并将其放置于/lib目录。my god，要自己写C库的源代码吗？不用！还记得交叉编译工具链的3个组成部分吗？交叉编译器、for ARM的C库和二进制工具。哈哈，for ARM的C库是现成的，我们只需要拷贝过来就可以了。遗憾的是：整个C库目录下的文件总大小有26M。而我们根文件系统所在分区不过区区16M而已，根本放不下。怎么办呢？ denni

49、sdennis-desktop:/work/nfs_root/fs_mini3$ du -s -si /work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib26M /work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib 需要C库目录下所有的文件吗？no，absolutely no! 让我们来分析一下glibc库目录下内容的组成。该目录下的子目录和文件共分8类： 目标文件，如crtn.o，用于gcc链接可执行文件 libtool库文件（.la），在链接库文件时这些文件会被用到，比如他们列出了当前库文件所依赖的其它库文

50、件，程序运行时无需这些文件 gconv目录，里面是各种链接脚本，在编译应用程序时，他们用于指定程序的运行地址，各段的位置等 静态库文件（.a），例如libm.a，libc.a 动态库文件 （.so、.so.0-9*） 动态链接库加载器ld-2.3.6.so、ld-linux.so.2 其它目录及文件很显然，第1、2、3、4、7类文件和目录是不需要拷贝的。由于动态链接的应用程序本身并不含有它所调用的C库函数的代码，因此执行时需要动态链接库加载器来为它加载相应的C库文件，所以第6类文件是需要拷贝的。除此之外，第5类文件当然要拷贝。但第5类文件的大小也相当大。dennisdennis-desktop

51、:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ du -c -si *.so* 7.2M total 需要全部拷贝吗？非也，非也！其实，需要哪些库完全取决于要运行的应用程序使用了哪些库函数。如果我们只制作最简单的系统，那么我们只需要运行busybox这一个应用程序即可。通过执行 dennisdennis-desktop:/work/nfs_root/fs_mini3$ arm-linux-readelf -a bin/busybox | grep Shared0 x00000001 (NEEDED) Shared library: libcr

52、ypt.so.10 x00000001 (NEEDED) Shared library: libm.so.60 x00000001 (NEEDED) Shared library: libc.so.6 可知：busybox只用到了3个库：通用C库（libc）、数学库（libm）、加密库（libcrypt），因此我们只需要拷贝这3个库的库文件即可。但是每个库都有4个文件，4个文件都要拷贝吗？当然不是。 dennisdennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ ls -l libcrypt.-*-rwxr-xr-x

53、1 dennis dennis 30700 2008-01-22 05:32 libcrypt-2.3.6.so-rw-r-r- 1 dennis dennis 23118 2008-01-22 05:32 libcrypt.alrwxrwxrwx 1 dennis dennis 13 2008-12-22 15:38 libcrypt.so - libcrypt.so.1lrwxrwxrwx 1 dennis dennis 17 2008-12-22 15:38 libcrypt.so.1 - libcrypt-2.3.6.sodennisdennis-desktop:/work/tools

54、/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ ls -l libm.-*-rwxr-xr-x 1 dennis dennis 779096 2008-01-22 05:31 libm-2.3.6.so-rw-r-r- 1 dennis dennis 1134282 2008-01-22 05:32 libm.alrwxrwxrwx 1 dennis dennis 9 2008-12-22 15:38 libm.so - libm.so.6lrwxrwxrwx 1 dennis dennis 13 2008-12-22 15:38 libm.so.6 - libm-

55、2.3.6.sodennisdennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ ls -l libc.-*-rwxr-xr-x 1 dennis dennis 1435660 2008-01-22 05:48 libc-2.3.6.so-rw-r-r- 1 dennis dennis 2768280 2008-01-22 05:31 libc.a-rw-r-r- 1 dennis dennis 195 2008-01-22 05:34 libc.solrwxrwxrwx 1 dennis dennis 13 2008-

56、12-22 15:38 libc.so.6 - libc-2.3.6.so 4个文件中的.a文件是静态库文件，是不需要拷贝的。另外3个文件是： 实际的共享链接库：libLIBRARY_NAME-GLIBC_VERSION.so。当然需要拷贝。 主修订版本的符号链接，指向实际的共享链接库：libLIBRARY_NAME.so.MAJOR_REVISION_VERSION，程序一旦链接了特定的链接库，将会参用该符号链接。程序启动时，加载器在加载程序前，会检索该文件。所以需要拷贝。 与版本无关的符号链接，指向主修订版本的符号连接（libc.so是唯一的例外，他是一个链接命令行：libLIBRARY_

57、NAME.so，是为编译程序时提供一个通用条目）。这些文件在程序被编译时会被用到，但在程序运行时不会被用到，所以不必拷贝它。关于共享库的2个符号链接的作用的特别说明：当我们使用gcc hello.c -o hello -lm编译程序时，gcc会根据-lm的指示，加头（lib）添尾（.so）得到libm.so，从而沿着与版本无关的符号链接（libm.so - libm.so.6）找到libm.so.6并记录在案（hello的ELF头中），表示hello需要使用libm.so.6这个库文件所代表的数学库中的库函数。而当hello被执行的时候，动态链接库加载器会从hello的ELF头中找到libm.

58、so.6这个记录，然后沿着主修订版本的符号链接（libm.so.6 - libm-2.3.6.so）找到实际的共享链接库libm-2.3.6.so，从而将其与hello作动态链接。可见，与版本无关的符号链接是供编译器使用的，主修订版本的符号链接是供动态链接库加载器使用的，而实际的共享链接库则是供应用程序使用的。通过以上分析，我们只需要拷贝3个库（每个库各1个主修订版本的符号链接和1个实际的共享链接库）以及动态链接库加载器（1个符号链接和1个实体文件）。步骤如下：dennisdennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/li

59、b$ mkdir /work/nfs_root/fs_mini3/lib dennisdennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ cp libcrypt-* /work/nfs_root/fs_mini3/libdennisdennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ cp -l libcrypt.so.* /work/nfs_root/fs_mini3/libdennisdennis-desktop:/work/tools/gc

60、c-3.4.5-glibc-2.3.6/arm-linux/lib$ cp libm-* /work/nfs_root/fs_mini3/libdennisdennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ cp -l libm.so.* /work/nfs_root/fs_mini3/libdennisdennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ cp libc-* /work/nfs_root/fs_mini3/libdennisde