第43卷    计  算  机  学  报  Vol. 43 2020  论文在线号No.6  CHINESE JOURNAL OF COMPUTERS   2020Online No.6 ——————————————— 本课题得到国家工信部2017年工业转型升级专项项目-工业控制系统核心技术能力提升的资助.余劲，男，1982年生，博士研究生，中国计算机学会（CCF）会员，主要研究领域为操作系统安全、虚拟化技术和云计算，E-mail: vigorousfish@gmail.com.  黄皓，男，1957年生，博士，教授，博士生导师，主要研究领域为系统软件、信息安全，E-mail: hhuang@nju.edu.cn.  诸渝，男，1990年生，硕士研究生，主要研究领域为系统与深度学习安全， E-mail: zhuy0416@163.com.  许封元，男，1983年生，博士，教授，博士生导师，主要研究领域为系统安全、边缘计算和大数据驱动安全，E-mail: fengyuan.xu@nju.edu.cn.   DBox：宏内核下各种设备驱动程序的高性能安全盒 余劲1) ,2)  黄皓1), 2)    诸渝1), 2)    许封元1), 2) 1)(南京大学软件新技术国家重点实验室  南京  210093) 2)(南京大学计算机科学与技术系  南京  210093)  摘  要  越来越多和宏内核操作系统中使用的设备驱动程序相关的漏洞被发现，这些漏洞严重危害操作系统的安全性和可靠性。现有的解决方案无法既能为操作系统内核提供强有力的保护又能达到与原生系统相近的性能。在本文中，我们提出了一个称为DBox的驱动程序隔离框架解决方案同时考虑系统的安全性和性能。DBox为设备驱动程序提供了一个安全的容器，并通过通用I/O 交互接口实现对多种设备驱动的支持。DBox深度优化了I  /  O 性能，在大多数情况下DBox中的驱动程序都可以达到与原始内核相同的性能。在DBox中添加新驱动程序支持无需修改该驱动程序代码，使得DBox方案在现实环境中易于采用。我们在DBox中实现了四个常见驱动程序类别（NIC，块设备，UART和输入设备），经过实验表明，TCP / UDP吞吐量、往返时延、块设备吞吐量、串口吞吐量、串口往返时延及键盘响应时间的性能下降均在5%以下。  关键词  驱动程序；隔离；虚拟化；  操作系统 中图法分类号：TP309    DBox：  宏内核下各种设备驱动程序的高性能安全盒 YU Jin1), 2)  HUANG Hao1), 2)  ZHU Yu1), 2)     XU Fengyuan1), 2) 1)(State Key Laboratory for Novel Software Technology, Nanjing University, Nanjing 210093) 2)(Department of Computer Science and Technology, Nanjing University, Nanjing 210093)  Abstract  More and more vulnerabilities have been discovered on device drivers used in monolithic kernels and thus  seriously  jeopardize  the  security  and  reliability  of  commodity  OSs.  Existing  approaches  resolving  above issue either do not offer strong protections for the OS kernels or suffer the performance degradation compared to the  original  I/O  performance.  In  this  paper,  we  propose  a  driver  isolation  framework  called  DBox  with  the consideration of both security and performance. DBox offers secure containers which can host device drivers and advanced common I/O exchanging APIs for universal driver supports. Moreover, DBox deeply optimizes the I/O performance so that in most cases drivers in DBox are able to achieve the same performance as in the original kernel. Adding a new driver support in DBox no need to modify  the driver's code, which makes Dbox easy to adopt  in  practice. We  implement  DBox  with  the  initial  support  of  four  common  driver  categories,  NIC,  block device,  UART,  and  input  accessories.  Experiments  show  that  the  performance  drops  of  TCP/UDP  throughput, round  trip  time,  block  device  throughput,  serial  port  throughput,  serial  port  round  trip  time,  and  keyboard response time are all below 5%. 网络出版时间：2020-01-20 17:15:03网络出版地址：http://kns.cnki.net/kcms/detail/11.1826.TP.20200120.1640.006.html2  计  算  机  学  报  2020年   Key words  driver; isolate; virtualization;     1  引言 宏内核操作系统提供了一种可加载的内核模块机制，设备驱动程序以内核模块的形式加载到内核后，将作为内核的一部分运行，并具有所有特权。有漏洞的驱动程序可能会损坏内核数据或使内核崩溃。远程攻击者还可以使用恶意驱动程序来使内核崩溃，获取机密信息或提升特权。由于宏内核架构的原因，设备驱动程序的漏洞是操作系统安全的主要问题。到2018年5月，已报告的CVE已达到200多个1并继续增长。自研究界意识到这是一个严重而重要的问题以来，已经提出了许多对策。但是，在实际的主要运用中很难找到在安全性和性能要求上都达到高标准的解决方案。例如，在用户空间[1][2][3]运行部分驱动程序，此类方法无法将内核与易受攻击的驱动程序完全隔离，并引入上下文切换的额外性能开销。通过页表限制驱动程序访问权限[5][6][7][8]，在内核API或驱动程序接口函数被调用时产生的页表切换，内核分配或释放动态数据块时产生的页表权限修改与检查动作，以及监视内核API调用情况的动作频繁出现时，会造成明显的性能开销。方案[8]需要在堆上分配内存并虚拟化某些内核数据结构，增加了安全风险。将整个驱动程序放入虚拟机VM ( Virtual Machine )[9][10][11][12][13]确实可以大大降低主机中内核的安全风险，但是这种方法引起的开销也非常大。此外，它们中的许多还需要大量的编程工作来修改操作系统  OS  (  Operating System )  和/或驱动程序，以实现其设计。因此，现有方法尚未在现实世界中广泛采用，脆弱的驱动程序仍然威胁着商用操作系统。 为了在操作系统上实现安全的驱动程序隔离，我们提出了一种实用的跨层设计，该设计可以充分利用软件和硬件功能来提供原始设备驱动程序的隔离，而不会降低性能。更具体地说，我们采用的设计在OS内核方面只需要进行最小的修改，就可以在大多数情况下实现与其I  /  O 性能非常相似的性能。对于注重安全性和系统性能（尤其是I / O性                                                                 1 Device  driver  vulnerabilities  on  Linux, http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+driver, 2018, 1, 4 能）的用户，我们的设计在实践中提供了一种友好的选择。 我们的设计叫做DBox，它是针对原始设备驱动程序基于虚拟化技术和x86架构特性的的面向性能的“盒子”框架。它在主机OS中提供了一个基于VM的驱动程序盒，用于隔离驱动程序，称为设备驱动虚拟机DDVM  (  Device  Driver  Virtual Machine  )，并提供了相应的DDVM管理组件和高效的I  /  O 接口，命名为通用通信接口驱动CCID ( Common Communication Interface Driver )。DDVM具有足够的通用性，可以通过最少的修改来托管各种设备驱动程序。  CCID是添加到主机内核中的轻量级内核模块，无需更改其他内核子系统中的代码。  因此，采用DBox很容易。此外，DBox引入了一套统一的I / O交换API，以实现通用驱动程序隔离，并基于常用的CPU特性高度优化其性能。  我们的评估结果表明，这种跨层优化的基于VM的I / O模型替代当前宏内核驱动程序模型，可以将易受攻击的驱动程序代码移入可信代码基TCB ( Trusted Code Base )。 我们在DBox中引入了一些I / O性能优化，使得在大多数情况下与当前的宏内核相比能够达到接近本机的性能。  第一个是在DDVM中的主机内核和驱动程序之间进行零拷贝批量数据传输。这是通过引入非内核管理的内存作为两侧之间的共享内存来实现的。这部分内存由DBox管理，以实现地址转换和映射，物理上连续内存的分配以及零拷贝。第二个是利用硬件功能来减少上下文切换的快速消息传递机制。通过这种优化，CCID消息传递增加的等待时间可以忽略不计。第三个是使DBox并行运行，提供专用的核心来处理其I / O请求和消息传递。  鉴于硬件的发展趋势，我们可以设想，从高层I / O应用程序的角度来看，托管在DBox中的驱动程序与在宏内核中的驱动程序之间没有区别。   本文的主要贡献包括： 1、  我们提出了具有统一I  /  O 接口的驱动程序隔离框架。  DBox旨在承载所有类型的设备驱动程序，并在大多数情况下将其与宏内核安全地分离，而性能下降最小。  通过应用跨层设计原理，  余劲等：DBox：  宏内核下各种设备驱动程序的高性能安全盒  3  DBox 的统一接口与以前的工作相比大大减少了开销，并防止内核受到易受攻击的驱动程序的威胁。 2、  我们通过多种技术优化DBox，以使DBox内部的驱动程序性能恢复到与DBox外部的驱动程序接近的水平。  DBox利用快速中断和cpuid指令来实现高性能的消息传递机制，从而避免了费时的上下文切换和同步。  为了减少内核内存管理的干扰并增强数据传输，DBox引入并管理了一块不受内核管理的共享内存，该共享内存是一块连续的物理内存，有利于直接内存存取Direct Memory Access ( DMA ) 操作；  DBox包含一个地址解析模块，用于将不可见的内存地址转换为内核可以理解的虚拟地址，以便DBox可以使用英特尔的直接I/O虚拟化技术VT-d ( Intel  Virtualization  Technology  for Directed I/O )2来增强主机与设备之间的数据传输。 3、  我们在Linux内核上使用针对x86架构的KVM (  Kernel-based  Virtual  Machine )支持来实现DBox。  大约2100行代码（其中大多数位于一个独立的内核模块中）被添加到内核中，因此DBox可以轻松部署，并且对内核的其他子系统的干扰最小。  我们的实现支持四个主要的驱动程序类别，并且实验结果表明DBox能够实现1％-5％的性能下降。  这证明了在硬件不断发展的情况下，可以用这种安全的驱动程序模型替换当前的驱动程序模型。 2  设备驱动安全盒DBOX的设计   在宏内核操作系统架构下，Dbox 提供了一个驱动程序的隔离运行环境，在保证隔离的前提下竟可能的保证性能。为了快速实现我们的设计，我们假定了操作系统是Linux，体系是x86，并在KVM上构建了Dbox，以及管理和服务Dbox的Linux 内核模块。其它宏内核操作系统可以利用我们的设计思想快速的实现相关组件并构建整个系统。在本节中，我们会从安全模型，设计目标，宏观设计的描述，包括性能优化的关键点。 2.1  安全模型及设计目标 我们关注的是由设备驱动程序引起的系统安全风险。这些风险包括来自受到威胁的驱动程序的                                                                 2     Intel  Virtualization  Technology  for  Directed  I/O, https://software.intel.com/sites/default/files/managed/c5/15/vt-directed-io-spec.pdf, 2019, 12, 27 未经授权的内核内存访问3,4，利用有漏洞的驱动程序5,6的root 特权升级，以及由恶意驱动程序触发的内核崩溃7,8,9,10。我们依靠先前提出的方法来防止驱动程序数据泄露。 我们在设计DBox时遵循以下目标：（1）安全地将设备驱动程序与宏内核解耦，并以类似微内核的方式在没有root特权的情况下运行它； （2）使用DBox优化内核的I / O性能使其接近原始性能； （3）支持各种未修改的设备驱动程序，并最小化对整体内核的修改； （4）使DBox易于被通用OS所采用。 2.3  宏观设计 综上所述，我们的DBox设计被认为既安全又具有高性能，因此可以在实践中轻松采用。回顾第1节中的描述，基于VM的盒子是DDVM，内核模块是CCID。引入了统一的I / O交换API，并且利用内核和CPU功能来实现这些API的跨层性能优化。 简而言之，DBox是在不牺牲I / O性能的情况下安全可靠地隔离宏内核中原始设备驱动程序的轻量级框架。  它由DDVM和CCID两个组件组成。 DDVM是一个通过KVM创建的安全容器，用于“装箱”宏内核的原始驱动程序。  CCID是一个主机内                                                                 3   ALSA  driver  vulnerability,   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000380,  2019, 12, 27 4   vhci_hcd  driver  vulnerability,   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16911, 2019, 12,   27 5   arcmsr  driver  vnlnerability, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7425,  2019,  12, 27 6   ALSA  driver  vulnerability, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0861,  2019,  12, 27 7   RTL8169  NIC  driver  vulnerability,   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1389,  2019,  12, 27 8   brcm80211  driver  vnlnerability, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8658,  2019,  12, 27 9   uas  driver  vnlnerability, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16530, 2019, 12, 27 10   ext4  driver  vnlnerability, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1094,  2019,  12, 27 4  计  算  机  学  报  2020年  核模块，用于管理DDVM，并在主机内核和DDVM之间提供高度优化的通信机制。  CCID是主机内核的一个附加部分，无需修改现有内核组件，它可以充分利用常用的CPU特性以提高性能。这种深入的跨层设计方法为商用OS展示了一种优化方法，即随着硬件的进步，用基于VM的松耦合驱动程序模型替代当前的驱动程序模型。 关于我们的性能改进，基于我们的共享内存设计实现了有效的通信接口，该接口管理内核不可见的内存，并提供适用于DMA的物理连续内存块。 快速中断和cpuid指令用于实现同步的通知和数据传输，以避免额外的数据复制并最大程度地减少上下文切换。  引入了地址解析模块，以将不可见的共享内存地址转换为虚拟可寻址的内存地址，从而可以使用VT-d来加快主机与设备之间的数据传输。 在下面的小节中，我们将介绍DDVM和CCID这两个组件。 2.4 DDVM DDVM是原始宏内核驱动程序的基于VM的托管容器。  与普通VM相比，DDVM附带了一个窄的服务层，可处理来自VM和DMA外部的交互。 设备驱动程序的请求将分派到适当的VM内或VM外组件进行处理。  主机和DDVM之间与I / O相关的操作非常耗时，并且会导致性能下降。  因此，我们致力于减少VM对外的交互次数并优化其性能。  鉴于多核的流行，我们使用并行运行和专用处理器核心来消除可能的延迟开销。  对于大量数据传输，我们依靠DMA来提高吞吐量。 为了在DDVM中的主机内核模块和设备驱动程序之间获得高性能的控制权转换，我们将两个实体并行设置在不同的CPU核心上运行。  通过消息传递来传递函数调用需要的参数，并通过快速中断来通知函数调用事件。  它使通信对等方可以立即注意到。详细信息将在第4节中讨论。 2.5 CCID 在两个不同地址空间中的两个实体之间的交互模拟了内核功能模块和设备驱动程序之间的过程调用之后，我们必须提供串行服务，例如通用接口，消息管理，共享内存管理，事件通知，数据指针翻译。我们设计并实现了专门的模块来提供这些服务。 通用通信接口：为了在DDVM中提供主机内核与各种设备驱动程序之间的通用通信机制并最大程度地避免对主机内核的修改，我们在主机内核与DDVM之间实现了一个通用的通信接口框架，称为CCID（  图2）。  CCID将交互模式从函数调用更改为消息传递，其分为主机系统中的CCID_HOST 和DDVM 中的CCID_DDVM。CCID_HOST为主机内核模块提供设备驱动程序的仿真接口（例如网络协议，文件系统），表示为，CCID_DDVM提供了主机内核模块的仿真接口。从分布式计算的角度来看，CCID_HOST 和CCID_DDVM构成了通信中间件。主机内核或DDVM中的设备驱动程序可以像在本地系统中一样在CCID_HOST  /  CCID_DDVM中调用这些接口。 共享内存上的动态内存分配：  在主机内核中的功能模块将数据发送到设备驱动程序之前，它必须从内存中分配不同大小的数据缓冲区以存储数据。  如果我们使内核功能模块和驱动程序可以动态分配并释放共享内存中的数据缓冲区，则主机内核和DDVM之间将不会有数据拷贝。我们在共享内存上为所有功能模块和设备驱动程序设计了一个动态内存分配接口，替换原有内核提供的内存分配接口。 消息管理：  如上所述，当主机内核中的功能模块需要调用隔离设备驱动程序的接口时，它必须将用于事件通知的通知消息发送到DDVM中的隔离设备驱动程序。  我们在CCID中设计并实现了消息传递管理子模块，该模块维护循环消息队列，并提供消息创建，接收，删除等服务。 共享内存上的数据指针转换：  尽管主机内核中的功能模块和DDVM中的设备驱动程序将数据放入共享内存中，并在通知消息中携带指向缓冲区内存地址的指针，但是由于两个实体位于不同的地址空间中，无法直接引用缓冲区的地址。  因此，我们设计并实现了一个接口，用于在两个不同地址空间之间转换数据指针。 高效的I / O操作：VT-d可用于增强虚拟机中I / O操作的性能。  为了设计易于部署的体系结构，最小化主机内核的修改并提高隔离级别，我们创建的共享内存对于主机内核中的内存管理模块和DDVM都是不可见的。  因此，DDVM中的设备驱动程序和DMA功能无法直接访问共享内存中的内存。  我们通过修改输入输出内存管理单元IOMMU ( Input/output Memory Management Unit ) 地址转换表以及DDVM中少量的DMA函数解决了这个问  余劲等：DBox：  宏内核下各种设备驱动程序的高性能安全盒  5  题。 安全：在将驱动程序移至DDVM之后，内核模块此时无法直接调用DI接口，并且驱动程序也不能直接将数据传输到内核模块。远程攻击者只能使用驱动程序来攻击DDVM内核，而不能攻击主机内核。  如果DDVM崩溃或没有响应，我们可以快速重新启动DDVM以恢复正常状态。 3  性能优化 在上一节中，通过介绍DBox设计简要介绍了关键性能优化。  在本节中，我们将详细解释这些性能改进。 3.1  并行处理 通常，这种基于VM的解决方案会导致大量的控制权转移，引入费时的上下文切换。  因此，性能下降是我们必须面对的主要问题。控制权转移主要包含两个步骤，信息传递（例如函数的参数）和新的代码触发执行（例如执行call，jmp，trap 等指令）。如果通过上述方法在两个地址空间之间进行控制权转移，会触发上下文切换。为了解决这个问题，我们提出了一种基于多核处理器系统的主机内核与DDVM之间的并行交互方法。  首先通过绑定不同的CPU核心，使DDVM和主机内核在不同的核心上并行运行。将控制权转移分为两个单独的部分，即消息传递和事件通知，尽可能的减少上下文切换过程。通过核间中断完成向对方的事件通知，该中断只会产生很少的可以忽略的额外操作。例如，当主机内核中的网络协议堆栈具有要发送到另一个CPU内核上运行的DDVM中的网卡NIC ( Network Interface Card ) 驱动程序的数据时，它只是向NIC驱动程序发送消息并通知它，并继续执行其他任务。  它节省了上下文切换时间，还减少了CPU缓存丢失的情况。 3.2  高效的消息传递 下一个问题是如何使处理器内核绑定到DDVM，以立即注意到并处理消息。  周期轮询和轮询方法可能会起作用。  但是周期轮询将导致响应延迟，而轮询方法将浪费大量cpu 时间。  与轮询方法相反，我们提出了一种使用快速中断和cpuid指令的通知方法。  当主机内核中的模块将消息发送到DDVM中的设备驱动程序时，它使用基于英特尔芯片的高级可编程处理器虚拟化功APICv ( Advanced  Programmable  Interrupt  Controller )Error! Reference  source  not  found.的快速中断来通知DDVM中的隔离驱动程序立即处理事件消息。另一方面，当DDVM中的设备驱动程序向主机内核中的模块发送消息时，它将执行携带特殊参数的cpuid指令，以便可以切换到主机内核处理此事件，该事件仅触发一次VMexit。如果消息队列中仍有一些消息在等待处理，发送者只是将消息放入环中，而不会再次通知接收者。在多核系统中频繁进行请求和响应I / O操作的情况下，会导致CPU花费过高的利用率来处理I/O 请求。因此，我们还尝试绑定一个cpu核心来专门轮询和处理即将到来的消息。我们分别将上述两种情况称为通知模式和半轮询模式。  Dbox可以根据不同的应用场景切换这两种模式。我们研究了各种方法，例如快速中断，中断注入和半轮询。实验表明，对于最常见的应用情况，快速中断是最有效的方法。 3.3  零拷贝和批量数据传输 在DDVM中隔离设备驱动程序之后，主机内核和DDVM的内存空间也将分离。  由于必须将数据从一个地址空间传输到另一个地址空间，因此通常会导致耗时的数据复制。  显然，高效的批量数据传输是另一个关键问题。 在主机内核和DDVM之间创建共享内存可以解决此问题，但仍然是一个关键问题，即Linux内核提供的共享内存服务不能保证物理内存是连续的，这可能无法满足DMA的连续内存要求。  此外，如果使用Linux内核共享内存服务，则应在主机内核的内存管理中进行许多修改，这会使解决方案部署起来过于复杂。因此，我们通过在主机内核和DDVM内核的初始化阶段保留足够的连续物理内存，为主机内核和DDVM构建连续的共享内存。 在DDVM内核中，设备驱动程序必须获取主机内核放入的共享内存中的数据，然后将其传输到设备驱动，反之亦然。  默认情况下，设备驱动程序无法通过DMA读写共享内存，因为DDVM内核的DMA功能无法获取共享内存的客户机物理地址GPA ( Guest Physical Address )，并且虚拟机管理器VMM (  Virtual  Machine  Manager  )无法将共享内存的GPA转换为主机物理地址HPA  (  Host  Physical Address ) 供DMA控制器使用。如图1所示，我们修改了DMA函数和VMM的一些代码以实现高性能的设备I / O。  首先，我们使用VT-d来使DDVM中的驱动程序可以直接访问设备，而无需管理程序6  计  算  机  学  报  2020年  的介入来增强设备I / O的性能。  由于我们在引导阶段保留了大块连续内存以用作DDVM和主机内核之间的共享内存，因此对于DDVM和主机内核中的内存管理，共享内存是不可见的。为了解决这个问题，我们在DDVM中修改了一些DMA函数，修改了IOMMU地址转换表和EPT表，以便共享内存可以分别由CCID_HOST，CCID_DDVM和DMA控制器使用，如图2所示。 Host kernel ( root ring 0 )HardwareDDVM kernel( non-root ring 0 )CCIDDDVMCCIDHOSTShared Memory cpuidfast i nterrupt Devi ce DriverPMMMNETFSManaged by MM ofHost and DDVMModifiedIOMMU table ModifiedEPT DataBufferMessgeRingDMA ControlerDevi ceDMA Functions 图1  主机内核子系统通过CCID与DDVM中的隔离设备驱动程序进行通信。 主机内核子系统通过快速中断通知DDVM，DDVM通过cpuid通知主机内核子系统。 它们通过共享内存传输消息和批量数据。 4  设备驱动安全盒DBOX的实现 4.1  批量连续共享内存构建 因为共享内存是Dbox实现的基础，所以我们首先讨论共享内存的实现细节。 为共享内存预留物理内存块：  Linux内核提供了几种用于内存分配的接口功能，例如alloc_pages，kmalloc，vmalloc。  alloc_pages和kmalloc可以分配连续的物理内存段，但是当没有空闲的连续物理内存块时它们可能会执行失败。  即使vmalloc成功分配了足够的连续虚拟内存部分，映射到刚分配的连续虚拟内存部分的物理内存也可能不是连续的。为了保证在DDVM和主机内核之间成功分配大容量连续的物理内存，我们在内核初始化期间分配了所需的连续物理内存。我们假设sys_size =“主机的物理内存的实际大小”，res_size  =“共享内存的所需大小”，vm_size  =“整个DDVM的物理内存大小”。  我们在主机的grub.conf中将最大可用物理内存参数设置为“  mem = sys_size-res_size”，该参数会在引导阶段转移到主机内核。  在DDVM创建命令中，我们在Qemu命令行参数中设置如下参数“−m vm_size mem = vm_size − res_size”，这表示虚拟机监控程序为DDVM提供的物理内存大小为vm_size（表示为-m vm_size），在DDVM的内核引导阶段，物理内存大小设置为vm_size-res_size（由mem  =  vm_size-res_size 表示）。  此时为主机和DDVM保留了所需数量的连续物理内存部分（共享内存的大小）。 内核初始化后，我们使用ioremap_cache 将保留的物理共享内存部分映射到连续的主机内核虚拟地址空间，并在DDVM中进行相同的操作。   尽管物理内存是在DDVM的内核页表中保留并映射的，但是此保留内存部分的HPA和GPA尚未映射到扩展页表EPT（Enhanced Page Table）中。 我们将在下一部分中进一步描述HPA和GPA在EPT中的映射。 GPA到保留内存的HPA映射：在KVM中，使用EPT将GPA映射到HPA。  当VM尝试访问EPT未涵盖的GPA地址时，将触发EPT violation，  VM通过VM-exit将陷入到KVM。  KVM将在EPT中创建相应的表条目，并将GPA映射到空闲物理页的HPA。如果此时的GPA对应的是共享内存的部分，由于主机内核的内存管理模块不知道共享内存对应的物理内存，它不会将GPA 映 射 到vm_size-res_size到vm_size范围内的保留物理内存部分。为了解决此问题，我们通过修改KVM中EPT violation处理程序，将DDVM中保留的GPA范围映射主机内核中保留的HPA范围内。  图2描述了共享内存实现的细节。 4.2  设备I / O 修改IOMMU地址转换表。  如果启用了VT-d，则DMA不使用EPT查找GPA到HPA的映射，而是使用IOMMU地址转换表。  当DMA尝试访问内存位置时，IOMMU查找IOMMU地址转换表，以查找GPA映射的HPA，DMA读取或写入数据。  在实现中，我们修改了初始化IOMMU地址转换表的代 码 。  我 们 还 修 改 了KVM 中 的 函 数kvm_iommu_map_pages，以将保留内存部分的GPA映射到相应的HPA。 在 DDVM 中，DMA 处 理 功 能dma_map_signle_attrs 应将数据缓冲区的客户机虚拟地址GVA ( Guest Virtual Address )  转换为GPA。 由于数据缓冲区的GVA在DDVM的内存管理模块可见的范围内，因此原始功能dma_map_signle_attrs  余劲等：DBox：  宏内核下各种设备驱动程序的高性能安全盒  7  无法正确执行此工作。  为了解决此问题，我们修改了函数dma_map_signle_attrs，以便它可以将数据缓冲区的GVA正确转换为共享内存部分中的GPA。 图3描述了共享内存实现的细节。 Host Physical MemoryPreserved forShared Memorykernel subsystemPM MM NET FSHVA HPAPage tableKVMkernel subsystemPM MM NET FSGVA GPAPage tableioremap_cache()HardwareHost kernel DDVM kernelDMA controllerCCID_HOST ioremap_cache()GPA HPAEPTGPA HPAiommu tabletap_page_fault() 图2  DDVM通过EPT表访问“保留物理内存”部分。 设备通过iommu地址转换表访问保留的物理内存。 主机内核和DDVM内核通过ioremmap_cache将保留物理内存部分映射到自己的内核虚拟地址空间。 4.3  CCID的实现 CCID模块包含两个部分。  主机内核中的一个表示为CCID_HOST，而DDVM中的另一个表示为CCID_DDVM。  它由CCID驱动程序接口CDI (  Common  Driver  Interface )，CCID内核接口CKI ( Common  Kernel  Interface )，共享内存管理SMM ( Shared Memory Manager )，消息处理MP ( Message Proccessor )，消息通知MN ( Message Notifier )和数据重定向DR ( Data Redirector )  组成。  图3描述了主机内核和隔离的设备驱动程序之间的交互。 CDIPMMMFSNETHost kernel ( root ring 0 )HardwareDDVM kernel ( non-root ring 0 )KIMPMNDRSMMCCID_HOSTMallocFreeCKIPMMMFSNETMPMNDRSMMMessageFast interruptcpuidCCID_DDVMDriverDIKIManaged by MMOf the Host and DDVMShared memoryMallocFreeDI KI 图3：CCID分为CCID_HOST和CCID_DDVM两部分。 CCID_HOST包括CCID驱动程序接口（CDI），共享内存管理（SMM），消息传递（MP），消息通知（MN）和数据重定向（DR）。 CCID_DDVM与CCID_HOST具有相同的体系结构，只是用CCID内核接口（CKI）替换了CDI。 CCID驱动程序接口CDI和CCID内核接口CKI。  在CCID_HOST中，CDI提供了一组接口函数，这些接口函数具有与隔离驱动程序接口相同的原型和语义（具有完全不同的实现）。  我们在主机内核中注册它们，然后主机内核将它们视为驱动程序接口功能。  例如，当主机内核模块决定将数据发送到隔离的驱动程序时，它将调用相应的CDI接口函数。  然后，CDI接口功能将消息发送到CCID_DDVM，CCID_DDVM依次调用DDVM中驱动程序的接口功能。  在CCID_DDVM中，CKI提供了一组接口函数，以取代提供给DDVM中的设备驱动程序的内核接口函数。  当DDVM中的驱动程序将数据发送到CKI时，它将在CCID_DDVM中调用相应的接口函数。 共享内存管理SMM当主机内核模块有要发送到隔离设备驱动程序的数据时，它在共享内存中分配数据缓冲区并填充要发送的数据。  但是主机内核和DDVM 内 核 中 的 某 些 函 数 （ 例 如_netdev_alloc_skb，alloc_skb 等）无法直接在共享内存上分配内存。  为了解决这个问题，我们在SMM中设计了一个简化的版本，以实现对应模块的动态内存分配功能。  我们在CCID_HOST和CCID_DDVM中实现了所有必需的内存分配和内存释放功能，这些功能与主机内核和DDVM中的原始内存分配函数具有相同的原型。  我们用主机内核和DDVM中新实现的函数替换了原始函数。 当DDVM中的主机内核和驱动程序分配并释放数据缓冲区时，它们将在SMM中调用这些接口函数。 消息传递MP维护消息接收队列和消息发送队列。  这两个队列在共享内存上创建为循环队列。 MP还负责在两个队列中同步数据访问。 事件通知MN旨在通过使用快速中断和cpuid指令进行通知。  在CCID_HOST向CCID_DDVM发送消息后，它将向DDVM的vcpu发送一个特殊的核间中断IPI（Inter-Processor  Interrupt），并且DDVM中的一个特殊的IPI中断处理程序将处理此事件。  CCID_DDVM向CCID_HOST发送消息后，它将执行我们定义的特殊cpuid 指令，然后触发VM_exit。  特殊的cpuid处理程序将处理此异常。 在轮询模式下，我们分别在内核和DDVM中创建一个接收器线程，并分别将它们与CPU内核绑定，这些线程轮询消息队列以检查是否有新消息到来。 数据重定向DR计算由主机内核为DDVM中的驱动程序创建的数据的新地址，并且还计算由驱动程序在DDVM中为主机内核创建的数据的新地址。  DR还应该在DDVM中的主机内核和驱动程序之间传输的数据对象中计算新的指针值。 8  计  算  机  学  报  2020年  4.4  创建设备驱动程序虚拟机 我们使用虚拟机管理程序KVM创建标准的全虚拟化VM作为DDVM。  构建DDVM时有两个主要的要求。  首先，DDVM应该尽可能减少对内核的依赖性，以最大程度地减少DDVM与内核之间的交互。  我们仅为DDVM安装虚拟磁盘，以避免不必要的块设备访问。  其次，DDVM应该删除所有不必要的内核模块，并运行少量必要的系统进程。  实际上，DDVM仅需要加载模块CCID_DDVM和设备驱动程序，并运行脚本使初始化进程进入睡眠状态。  因此，DDVM是一个仅需少量内存运行的精简Linux内核。 4.5  隔离NIC驱动程序和块设备驱动程序的实例 图4描述了发送数据包的过程。  （1）用户应用程序调用系统调用以通过套接字发送消息。 （2）主机网络协议调用CCID_HOST的SMM的接口，为发送数据包分配skb对象和共享存储区中的数据缓冲区。  （3）主机网络协议在数据缓冲区中构造要发送给DDVM的数据包。  （4）主机网络协议调用CCID_HOST 的CDI 提供的接口函数ndo_start_xmit。  （5）CCID_HOST的MP将有关发送数据包的消息放入共享内存的循环队列中。 （6）CCID_HOST的MN通过使用快速中断向CCID_DDVM的MN通知数据包已经到达。  （7）CCID_DDVM的MP读取有关发送数据包的消息。 （8）CCID_DDVM的DR读取共享内存中的数据包。（9）CCID_DDVM的DR转换skb的虚拟地址并修改skb结构的某些指针成员的虚拟地址。 （10）CCID_DDVM的DR调用驱动程序的接口函数ndo_start_xmit来传递数据包。  （11）驱动程序通过DMA将数据包发送到NIC。 （12）驱动程序调用CCID_DDVM的SMM的接口以释放共享内存中的skb和数据缓冲区。 Tcp/ipstack② alloc skbCCIDDDVMCCIDHOST④ ndo_start_xmit⑤ put msg① syscall⑥ fast⑦ get msg⑩  ndo_start_xmit③ build skbNic driver ⑫ free skb⑧ read skbMPSMMMN MNMPinterruptDR⑪ sendSMMCDIDI⑨ rebuild skb 图4  主机内核TCP / IP堆栈将数据包发送到DDVM中的隔离NIC驱动程序 图5描述了接收数据包的过程。  （1）DDVM中的驱动程序调用CCID_DDVM的SMM接口为共享数据包分配skb和共享存储区中的数据缓冲区。 （2）DDVM中的驱动程序接收数据包并构造skb结构。（3）DDVM中的驱动程序调用netif_rx，该函数被CKI接口hook，以将数据包传输到CCID_DDVM。 （4）CCID_DDVM的MP将有关接收数据包的消息放入共享内存中的循环队列中。 （5）CCID_DDVM的MN执行自定义类型的cpuid指令，以通知CCID_HOST的MN有传入的分组。 （6）CCID_HOST的MP从循环队列中读取消息。 （7）CCID_HOST的DR读取共享内存中的数据包。 （8）CCID_HOST的DR转换skb的虚拟地址并修改skb 结构的某些指针成员的虚拟地址。  （9）CCID_HOST的DR调用接口函数netif_rx将数据包传输到主机TCP / IP 网络协议栈。（10）主机的网络协议栈处理数据包。 （11）主机的网络协议栈调用CCID_HOST的SMM的接口以释放共享内存中的skb和数据缓冲区。   余劲等：DBox：  宏内核下各种设备驱动程序的高性能安全盒  9  NicdriverCCIDHOST③ netif_rx⑥ get msg⑦ read skb⑨ netif_rxTcp/ip stack⑩ processCCIDDDVM④ put msg① alloc skb② recv skb⑤ cpuid⑪ free skb⑧ rebuild skbSMMCKIMPMN MNMPDRKISMM 图5  主机内核TCP / IP堆栈从DDVM中的隔离NIC驱动程序接收数据包。 图6描述了从块设备读取数据并将数据写入块设备的过程。  （1）用户应用程序调用读取或写入系统调用。  （2）主机块设备层调用CCID_HOST的SMM的接口在共享存储区中分配生物和数据缓冲区。  （3）主机块设备层构造bio对象。  （4）主机块设备层调用CCID_HOST的CDI提供的接口函数blk_make_request。  （5）CCID_HOST的MP在共享存储器的循环队列中放置一条有关读取数据的消息。  （6）CCID_HOST的MN通过使用快速中断来通知CCID_DDVM的MN bio已经到达。 （7）CCID_DDVM的MP读取有关读取或写入数据的消息。 （8）CCID_DDVM的DR读取共享内存中的bio。  （9）DR的DR转换bio的虚拟地址并修改bio  struct的某些指针成员的虚拟地址（例如 ： 将 函 数 指 针bi_end_io 的 点 更 改 为ddvm_bio_end_io）。（10）CCID_DDVM的DR调用DDVM内核的接口函数submit_bio 来传递bio。 （11）DDVM内核处理bio，最后通过块设备驱动程序从块设备读取数据或将数据写入块设备。 （12）驱动程序调用CCID_DDVM的CKI提供的接口函数bio_end_io。 （13）CCID_DDVM的MP在共享内存的循环队列中放入一条有关调用bio_endio的消息。  （14）CCID_DDVM的MN执行一种自定义类型的cpuid 指令，以通知CCID_HOST有一个准备好结束的bio。  （15）CCID_HOST的MP读取消息。 （16）CCID_HOST的DR调用主机内核提供的接口函数bio_endio。 （17）主机块设备层调用CCID_HOST的SMM的接口以释放共享内存中的生物和数据缓冲区。 Block Device layer② alloc bioCCIDDDVMCCIDHOST④ blk_make_request⑤ put msg① syscall⑥ fast⑩ submit_bio③ build bio⑪ read      write⑬ put msg⑫ bio_end_io⑧ read bio⑨ rebuild bioDDVM Block device layer⑭ cpuid⑮ get msg⑯ bio_endio⑰ free bioSMMCDIMPMNinterruptMNMP ⑦ get msgDRDICKIMPMN MNMPDR KISMM 图6：主机内核块设备层子系统提交一个bio到DDVM块设备层子系统读取或者写入数据到块设备。 4.6 Dbox中支持的多种设备驱动 我们的DBox实现支持4种驱动，分别是NIC，块设备，UART和输入设备。表1展示DBox支持的设备及相关驱动。我们通过设计DBox的核心组件  DDVM和CCID与主机内核拥有明确的边界，以及引入统一I/O 接口，使得这两部分的基本实现独立于特定的驱动。我们用了大约2000行C代码实现，为了将DBox与主机宏内核挂钩，我们在内核中增加了100行代码。需要注意的是，这些代码作为整个内核模块添加到内核中，或者插入到现有代码中，因而大大降低了我们的代码对内核更新和补丁的敏感性。对表1 中的每个新支持的驱动，DBox中仅需添加100-300行代码并且大多被用来驱动与统一I/O 接口的挂钩。因此，添加一个新的驱动支持简单明了，且代码存在相似性。我们计划在将来能够为DBox创建一个自动添加新的驱动程序支持的系统。 表1  Dbox支持的设备驱动 类型  驱动  设备 NIC  rtl8168.ko  rtl8168 nic 块设备  usb-storage.ko Orico Usb3.1 msata case Intel 530 msata 120GB ssd 10  计  算  机  学  报  2020年  mmc-core.ko SanDisk 16GB SDHC 10 mmc card sdhci.ko sdhci-pci.ko mmc-block.ko Uart  8250.ko 8250/16550A serial controller 输入设备 usbkdb.ko Plum 87 enhanced usb keyboard usbmouse.ko Razer ABYSSUS usb mouse 5  实验 5.1  环境设置 我们的实验环境是一台Intel  E5-2620  V4处理器（主频2.1GHz、8核、16硬线程）、32GB DDR4内存、1TB  SATA3硬盘、一块RTL8168千兆网卡以及一块西霸FG-EMT11A PCI-E串口卡的台式机。主机OS是带有KVM模块的Linux 3.8.0-29-generic 64-bits Ubuntu 14.04 LTS，DDVM OS是同版本的主机OS与busybox-2.23文件系统的精简Linux。我们在BIOS中启动EPT和VT-d并给DDVM配置2.1G x 2 CPU和64MB物理内存，同时用64MB物理内存作为共享内存。我们分配给主机OS 14条硬线程，将余下的2条绑定与DDVM绑定，同时将隔离设备的中断与DDVM的线程绑定。对于DDVM的轮询模式，我们将主机的一条硬线程与其内核中的接收器线程绑定，并且将一条DDVM中的硬线程与它的接收器线程绑定。最后我们准备了一台Intel i7-2720  2.2GHz  8核CPU、8GB  DDR3内存、1TB硬盘及1块千兆网卡的远程PC用于网络和串口的性能测试。远程PC运行Ubuntu 14.04 LTS OS。设备通过Intel VT-d于DDVM绑定。 5.2  性能实验 网络吞吐量测试。  性能是基于VM的驱动隔离模式的关键问题。我们使用主流的基准netperf对TCP_STREAM  TX、TCP_STREAM  RX、UDP_STREAM TX和UDP_STREAM RX进行网络吞吐量测试。在TX吞吐测试中，我们在主机上运行netperf并且在远程PC上运行netserver。对于RX吞吐测试，主机上运行netserver而远程PC上运行netperf。socket缓存大小设置为16384  bytes，数据包分别选择64、128、256、512、1024和2048 bytes。图7、图8、图9和图10显示与本机系统相比，除了在UDP_STREAM RX测试中数据包大小为64、128、256 bytes的情况之外，在TCP_STREAM TX、TCP_STREAM  RX和UDP_STREAM  TX的测试中，Dbox的吞吐量性能下降不超过1%。CPU利用率提高2.1倍至3.2倍。大部分的网络应用很少会使用较小的UDP数据包。比如，HTTP、FTP 和XMPP协议仅使用TCP作为各自的传输协议。尽管SIP、RTSP、RTP和TFTP协议能够使用UDP作为传输协议，数据包大小也超过256 bytes，其中TFTP协议数据包大小固定为512 bytes。  图7  在不同数据包大小下，本机系统，启用了VT-d的标准虚拟机和Dbox之间的TCP TX吞吐量比较  图8：在不同数据包大小下，本机系统，启用了VT-d的标准虚拟机和Dbox之间的TCP RX吞吐量比较。   余劲等：DBox：  宏内核下各种设备驱动程序的高性能安全盒  11   图9：在不同数据包大小下，本机系统，启用了VT-d的标准虚拟机和Dbox之间的UDP TX吞吐量比较  图10：在不同数据包大小下，本机系统，启用了VT-d的标准虚拟机和Dbox之间的UDP RX吞吐量比较 网络延迟测试。  我们还使用基准netperf 对TCP_RR和UDP_RR进行延迟测试。  我们在主机上运行netperf，在远程PC上运行netserver。  图11显示，在TCP_RR和UDP_RR的测试案例中，与启用VT-d的标准虚拟机相比，Dbox通知模式的性能下降为3.24％和5.15％，Dbox轮询模式的性能下降为2.99 ％和3.27％。  我们的CPU利用率是原生系统的2.1到3.2倍。  图11：本机系统，启用了VT-d的标准虚拟机和Dbox之间的TCP_RR和UDP_RR比较 块设备吞吐量测试。我们让SCSI块设备驱动程序和usb块设备驱动程序在DDVM中运行，让Orico  Usb3.1 msata移动硬盘盒和Intel  530  msata 120GB  ssd通过VT-d连接到DDVM。  在主机的shell上，我们运行命令“  dd if = / dev / ddvm of = / dev / null iflag = direct bs = X count = Y”以测试块设备读取吞吐性能，运行通用命令“  dd if = / “  dev / zero of = / dev / ddvm oflag = direct bs = X count = Y”来测试块设备的写入吞吐量性能。我们使用参数“  direct”来确保dd直接读写块设备而没有缓存。 我们将X的值设置为512、1K和4K，并设置Y的值以确保X * Y = 1GB。  图12和图13显示，与启用VT-d的标准虚拟机相比，Dbox通知模式的读写性能下降了8％-19％，Dbox轮询模式的读写性能下降了  3％-5％。  我们的CPU利用率是原生系统的2.1到3.2倍。  图12：在不同块大小下，本机系统，启用了VT-d的标准虚拟机和Dbox之间的块设备写入吞吐量比较 12  计  算  机  学  报  2020年   图13：在不同块大小下，本机系统，启用了VT-d的标准虚拟机和Dbox之间的块设备读取吞吐量比较 串口吞吐量测试。我们将linux 内核自带的8250/16550a串口驱动程序在DDVM中运行，让主机上的西霸FG-EMT11A PCI-E串口卡通过VT-d的方式绑定到DDVM中。远程PC通过串口线将自己的串口与主机串口卡的串口连接。我们通过编程实现了uart-client和uart-server 测试程序，由于串口单次发送数据大小受波特率和硬件限制，为了保证每次数据能发送完，我们设计由uart-client 向uart-server循环发送2KB的数据，每次发送完等待1秒，总共发送64KB。在uart-server 中记录收完64KB数据的时间并计算串口吞吐量。对于串口TX吞吐量，远程PC上运行uart-server，在主机上运行uart-client；在对于串口RX吞吐量，远程PC上运行uart-client，在主机上运行uart-server。我们设置了串口奇偶校验位为n，数据位为8，停止位为1，分别测试了在串口波特率为38400、57600和115200三种情况下的串口吞吐量。如图14和图15所示，Dbox的串口吞吐量性能下降不超过1%。  图14：在不同波特率下，本机系统，启用了VT-d的标准虚拟机和Dbox之间的串口设备TX吞吐量比较   图15：在不同波特率下，本机系统，启用了VT-d的标准虚拟机和Dbox之间的串口设备RX吞吐量比较 串口延迟测试。测试环境与串口吞吐量测试相同，我们设置固定波特率为115200，由uart-client向uart-server发送64 Byte的数据，uart-server收到数据后立刻向uart-client发送64  Byte的数据，在uart-client 中计算发送数据和收到数据之间的时间间隔。我们在主机上运行uart-client，远程PC上运行uart-server，连续测试100次，计算平均每次交互的时间间隔。如图16所示，与启用VT-d的标准虚拟机相比，Dbox通知模式的平均单次往返时间上升了7.96％，Dbox轮询模式的平均单次往返时间上升了3.67%。  图16：本机系统，启用了VT-d的标准虚拟机和Dbox之间的串口设备往返延时比较 键盘响应时间测试。由于没法模拟键盘产生的硬件中断，所以我们的实验主要测试从键盘驱动收到中断开始到/dev/input/event10事件文件收到键盘响应事件为止的时间间隔。我们将linux 内核自带的usb键盘驱动程序在DDVM中运行，让主机上的Plum  87  enhanced  usb 键盘通过VT-d的方式绑  余劲等：DBox：  宏内核下各种设备驱动程序的高性能安全盒  13  定到DDVM中。我们在键盘驱动中断处理程序中记录收到中断的时间，在主机中运行测试程序kdbtest，打开/dev/input/event10 事件文件，记录收到键盘事件的时间，连续执行100次，计算平均的时间间隔。如图17所示，和原生系统相比Dbox通知模式的键盘响应时间上升了5.37％，Dbox轮询模式的键盘响应时间上升了2.53%。  图17：本机系统和Dbox之间的键盘响应时间比较 5.3  安全性实验 在Linux内核v2.6.30之前，rtl8169  NIC 驱动程序具有严重的漏洞[1]。驱动程序中的函数rtl_set_rx_max_size 默认情况下设置数据包的最大长度16383。即使NIC接收到的数据包的长度比本地网络的MTU（例如，1,500）长（例如，由命令ping -s  3000生成的数据包），NIC仍会判断该数据包的长度未超过该长度局限性。因此，当驱动程序查询数据包长度时，NIC会将数据包的实际长度响应为3,000，随后函数skb_put使指针skb_tail指向skb缓冲区的偏移量3,000中的位置。另一方面，如果本地MTU为1500，则将所有skb缓冲区长度设置为1,500，并将指针skb-> end设置为skb缓冲区偏移1500中的位置。虽然驱动程序skb_put中的函数比较两个指针skb-> tail和skb-> end，但是skb-> tail 比skb->  end 大 的 结 果 将 导 致 函 数skb_over_panic触发内核panic。 相关的NIC硬件过于老旧，我们找不到它，因此我们在Dbox中为该实验构建了一个环境来模拟相同的情况，在该环境中，我们将参数pkt_size设置为3000，MTU为1500。  当我们将数据包发送到主机中的应用程序时，DDVM内核会出现内核panic，就像数据包到达DDVM一样，但是主机内核仍处于正常状态。此时由于主机系统中的CCID模块发现DDVM长时间未响应，记录当前DDVM镜像版本及相关信息，并通知应用层监控程序主动关闭DDVM，重新启动一份事先准备好的包含正常驱动程序的DDVM镜像，尝试恢复DDVM的正常运行。这里我们所采用的是一种简单的状态恢复方法，仅能恢复驱动层面的正常工作，与驱动相关联的上层应用程序由于底层驱动程序的重置，导致应用层上下文丢失，需要应用层程序手动重启，重建应用层上下文并恢复应用程序服务。我们会在后续的研究工作中研究如何能够自动保存和恢复用户态上下文的能力，做到真正实现全流程恢复运行状态的功能。综上所述，Dbox保护了主机内核，并通过重新启动DDVM尝试恢复驱动程序的执行。 6  相关工作 设备驱动程序的隔离机制可以分为三种类型：将设备驱动程序置于用户空间进程中；通过为每个隔离的设备驱动程序创建一个具有专有页表的单独地址空间来限制设备驱动程序；创建专用于隔离设备驱动程序的虚拟机。 6.1  用户空间中的设备驱动程序 UIO11是Linux 操作系统提供的一个可以在用户空间运行设备驱动程序的驱动框架简称。其内核部分构建了一系列设备文件和sysfs 的属性文件对象。内核部分负责映射设备内存、寄存器内存和上传设备中断事件。用户空间部分通过对设备文件的mmap，实现将硬件内存映射到用户态，使得用户程序中可直接访问硬件设备内存；通过read 或者select 等系统调用捕捉内核部分上传的设备中断事件。该框架主要是为了解决（接口卡、定制FPGA等）非标准设备驱动由于内核版本的频繁更替而使得驱动程序维护工作量大，内核体积增大等问题而提出的。网卡、磁盘等标准设备的驱动一般直接使用linux 内核已有的按设备类型划分的标准设备驱动框架，而不会使用UIO框架。UIO分为内核和用户态两部分，对设备驱动的隔离不完整。需要手动修改驱动代码后才能支持UIO框架。 Microdrivers[1]仅支持e1000 系列NIC驱动程序。  它将驱动程序分为用户空间中的较大组件和内核中的较小组件。  Microdrivers的性能开销为                                                                 11   The  Userspace  I/O  HOWTO, https://www.kernel.org/doc/html/v4.12/driver-api/uio-howto.html,  2019,  12, 27 14  计  算  机  学  报  2020年  6.3％，CPU利用率提高了30％。Qiang等[2]用户空间为驱动程序设计了一个代理驱动程序和一个操作系统库，并实现了最小化系统调用时间损耗。  当仅在用户空间中进行数据传输时，它具有9％-24％的性能开销。  以上两个系统都将设备驱动程序分为用户模式和内核模式，隔离不完整。  频繁的用户内核切换导致沉重的系统开销。 SUD[3]用户空间进程中模拟了未经修改的设备驱动程序的执行环境。它们还为特权I / O操作实现了内核模块。  SUD具有1％-3％的性能开销，  CPU利用率提高了11％-30％。  但是，由于SUD仍必须与内核模块进行交互，因此它不是完整的隔离解决方案。  此外，在用户空间过程中模拟Linux内核环境是一项艰巨的工作：它在用户空间中的基本框架有5000 LOC代码，一组修改后的内核模式API，最多有2800  LOC代码用于隔离设备驱动程序，并且为每个设备驱动程序必须提供17MB 内存。  相比之下，DBox仅增加了约2100 LOC代码来提供通用的通信接口，而每个设备驱动程序则不足300 LOC代码。 Herder等[4]提出了一种在Minix中隔离系统的驱动程序，该驱动程序通过限制CPU使用，内存访问，设备I / O访问和系统服务来限制驱动程序的执行最低权限。这项工作基于微内核操作系统，这是对我们在宏内核操作系统上设备驱动程序隔离方法的补充。 6.2  限制驱动程序访问权限 Gateway[5]实现了监视驱动程序调用的内核API。它为内核和驱动程序创建单独的页表，以拆分其地址空间，使监视不可绕过。为了降低性能开销，它通过使用CR3-target 更改non-root 客户机内核中的CR3寄存器的值来实现快速地址空间切换，以避免陷入虚拟机管理程序中。Gateway可以监视由恶意驱动程序调用的所有内核API，并支持36种常用的Linux驱动程序。HUKO[6]提出了一种称为多HAP的增强的内存虚拟化机制。通过使虚拟机监控程序能够控制不同主体的访问权限，它可以将不受信任的内核扩展模块与内核隔离。它控制HAP表条目的执行位，这会使得在虚拟机管理程序中捕获异常访问而导致保护状态切换。它同时试图减少保护状态切换的事件。  HUKO支持rtl8139 NIC设备驱动程序和EXT3模块。它们在网络吞吐量方面的性能开销为14％。以上两个工作都使用页表来隔离设备驱动程序。尽管它们尝试减少陷入数量，并为调用驱动程序接口函数或调用内核API的驱动程序的内核实现快速的地址空间切换，但是当内核分配或释放动态数据块时，将产生页面表切换、页表特权检查和修改等操作。因此，当上述事件发生时，它们将产生严重的性能问题。  我们的Dbox在通知模式下，最多从DDVM传输到主机的每个数据执行一次上下文切换，并且在轮询模式下不会触发任何上下文切换。  Gateway专注于监视使用VM的设备驱动程序，这与我们的目标不同。  与HUKO相比，我们的设计还支持更多类型的设备驱动程序。 LXFI[7]将内核模块与内核隔离，以防止利用内核模块漏洞的特权提升攻击。  LXFI通过对设备驱动程序调用内核API的原则、功能的监控，来隔离设备驱动程序。  他们的设计支持e1000  NIC，intel8x0 声卡，snd-ens1370 声卡设备驱动程序和econet网络协议，dm-crypt，dm-zero，dm-snapshot模块。  它们在TCP_STREAM上的TX性能下降了35％，在UDP_RR上的性能下降了14％，并且CPU利用率提高了2.2 倍至3.7 倍。  我们的设计在UDP_STREAM  TX和UDP_RR上均具有比LXFI更好的性能。 SIDE[8]，提出了一种隔离设备驱动程序的执行系统。在内核页表中，它取消映射设备驱动程序代码相关的页。当内核模块调用驱动程序的接口函数时，将发生页面错误。经过修改的页面错误异常处理程序将为特权级别为ring-3的隔离驱动程序代码创建执行环境，而不会触发TLB刷新。  SIDE实现了轻量级控制权转移，以保持高性能。巧妙的快速控制权转移机制体现了系统设计的卓越性。但是，SIDE在用户模式下的设备驱动程序，它仍然共享几乎所有的内核页表。隔离的驱动程序需要在堆中分配动态内存，并虚拟化一些内核数据结构。此外，隔离的驱动程序与内核是紧密耦合的，增加了安全风险。相反，在我们的Dbox设计中，DDVM中的主机内核和设备驱动程序是完全隔离的，并且通过在第4节中介绍的一系列性能优化机制，具有类似的高性能。 6.3  虚拟机中的设备驱动程序 Cinch[9]旨在保护免受恶意外围设备的攻击。 它将外围设备连接到逻辑上独立且不受信任的虚拟机，并在不受信任的虚拟机和主机之间插入一个插入层。  该层根据用户配置的策略来调节交互，从而以较低的开销阻止外部的攻击。  与Dbox的工  余劲等：DBox：  宏内核下各种设备驱动程序的高性能安全盒  15  作相比，Chariot监视VM中驱动程序的行为，而Cinch打算监视所连接的不受信任设备的行为，因此隔离设备驱动程序并不是他们的主要目标。 Chariot[10]是用于监视虚拟机中驱动程序状态的框架。  在系统中，他们将监视模块插入VM的OS内核中，并添加一些代码以在VMM中进行监视。  为了提高VM的可靠性并降低监视开销，它使用透明的机制来检测和恢复VM中驱动程序的故障。 Joshua等[11]提出了一种设备驱动程序重用和隔离方法，该方法在虚拟机中执行未修改的设备驱动程序。驱动程序通过增强直通方式直接控制设备，从而允许设备驱动程序OS（DD / OS）访问该设备。 VM禁止设备驱动程序及其中的OS访问属于其他VM的设备。客户端通过添加到DD / OS的转换模块与驱动程序连接。该模块将客户端请求映射到DD  /  OS原语序列中，以访问设备。它直接使用一些L4虚拟机管理程序机制来创建共享内存并实现批量数据传输。但是，在处理流程中仍然存在一些额外的数据拷贝，并且系统仅支持PCI NIC和SATA设备驱动程序。  此外，其用于发送和接收500-1,500字节数据包的网络吞吐量的性能开销为3％-8％。 CPU利用率提高了1.6倍至2.03倍。  相比之下，由于它们特定的交互模式，性能开销比Dbox高。 Sumpf等[12]提出在基于L4  /  Fiasco微内核的VM中隔离块设备驱动程序，以提供一种解决移植困难的方法。它实现了一种基于共享内存的高性能通信方法，并通过利用L4内存管理系统来实现DMA访问。此方法是针对L4/Fiasco 微内核操作系统的驱动移植问题，和我们的场景不相同。 Tan等[13]提出将ikernel作为隔离虚拟机中每个设备驱动程序的一种方法。  为了提高性能，ikernel将物理设备分配给特定的VM，以便VM可以直接访问该设备。它还使用共享内存在主机和并口设备驱动程序之间传输小型数据。ikernel的工作仅实现了并口设备驱动程序隔离，并且着重于增强驱动程序和设备之间的I / O操作性能，以替代Intel VT-d（尽管当时尚未发布）。尽管它使用共享内存进行通信，但它只是定期拷贝共享内存中的消息，这对于并口设备驱动程序是可行的，但是与具有高吞吐量和低延迟要求的其他设备驱动程序不兼容。 6.4  共享内存方法 virtsocket[14]是一个新的网络套接字库，它利用共享内存进行数据传输，以增强虚拟机上I / O密集型应用程序的性能。  根据调度程序，触发存储在环形缓冲区数据结构中的虚拟机的I  /  O 请求以仅在一个超级调用中发出所有请求。  主机内核模块直接从虚拟机内存读取I / O请求中引用的数据，而无需复制数据。  Nahanni[15]设计了一种用于VM间通信的数据传输机制。  它基于KVM创建了一个共享内存块，一个Qemu的虚拟PCI设备，并为VM提供了用户空间库。  与virtio相比，Nahanni可以减少29％的工作负载延迟和73％的读取操作延迟。 Patni等[16]提出一个名为virtIO-serial的设计，该设计实现了一个在KVM上多个VM之间可完成一般任务通信的快速通道。 以上所有工作的主要目标是增强两个VM或VM与主机之间的I / O通信性能，以及用于云计算平台上的应用程序。  尽管他们两个都在任务中使用共享内存，但是目标和要解决的问题与我们的Dbox不同。 7  结论 总之，我们基于虚拟化技术提出了一个面向性能的设备驱动程序隔离框架，称为DBox。  使用此框架，隔离的驱动程序不需要任何修改，而主机内核仅需增加一些挂钩点。  因此，DBox可以轻松地部署在通用操作系统上，并为易受攻击的宏内核驱动程序提供安全保护。 DBox由两个组件组成：DDVM和CCID。 DDVM是基于KVM创建的原始设备驱动程序的安全容器；  CCID是一个可加载的内核模块，为不同地址空间中的两个交互方提供通信服务。  CCID能够为运行在宏内核（如Linux）上的各种设备驱动程序提供服务，并使添加新驱动程序支持的工作量降到最低，通常约为一百行代码。 在性能优化方面，我们将并行任务调度技术用于控制权转移，为两个交互实体提出了并行通信机制；多核平台上用于事件通知的快速中断机制；基于非内核管理共享内存的零拷贝数据传输机制。 隔离的设备驱动程序和主机内核模块之间的交互性能与本机系统中的交互性能保持相似的水平。 实验表明，TCP / UDP吞吐量、往返时延、块设备吞吐量、串口吞吐量、串口往返时延及键盘响应时间的性能下降均在5%以下。 为了进一步提高部署的简便性，我们计划在将来研究内核中动态挂钩点插入的方法，以便部署16  计  算  机  学  报  2020年  DBox时不再需要重新编译内核。  致  谢  本文感谢所有的审稿者！     参 考 文 献 [1]  Ganapathy  V,  Balakrishnan  A,  Swift  M  M,  et  al.  Microdrivers:  A  new  architecture  for  device  drivers.  Network,  2007,  134:  27.8. [2]  Qiang  W,  Zhang  K,  Jin  H.  Reducing  TCB  of  Linux  Kernel  Using  User-Space  Device  Driver//  In  Proceedings  of  Algorithms  and Architectures  for  Parallel  Processing  (ICA3PP),  the  16th  International  Conference  on.  Granada,  Spain,  2016:  572-585. [3]  Boyd-Wickizer  S,  Zeldovich  N.  Tolerating  Malicious  Device  Drivers  inLinux//Proceedings  of  USENIX  Annual  Technical  Conference.  Boston,  Massachusetts,  USA,  2010:  117-130. [4]  Herder  J  N,  Bos  H,  Gras  B,  et  al.  Fault  isolation  for  device  drivers//  Proceedings  of  Dependable  Systems  &  Networks  (DSN),  the  39th  Annual  IEEE/IFIP  International  Conference  on.  Estoril,  Portugal，2009:  33-42. [5]  Srivastava  A,  Giffin  J  T.  Efficient  Monitoring of  Untrusted  Kernel-Mode  Execution//Proceedings  of  the  Network  and  Distributed  System  Security  Symposium  (NDSS).  San  Diego,  USA,  2011. [6]  Xiong  X,  Tian  D,  Liu  P.  Practical  Protection  of  Kernel  Integrity  for  Commodity  OS  from  Untrusted  Extensions//Proceedings of  the Network  and  Distributed  System  Security  Symposium  (NDSS),  San  Diego,  USA,  2011:  11. [7]  Mao  Y,  Chen  H,  Zhou  D,  et  al.  Software  fault  isolation  with  API  integrity  and  multi-principal  modules//Proceedings  of  the  Twenty-Third  ACM  Symposium  on  Operating  Systems  Principles.  New  York,  USA,  2011:  115-128. [8]  Sun  Y,  Chiueh  T.  SIDE:  Isolated  and  efficient  execution  of  unmodified  device  drivers//Proceedings  of  Dependable  Systems  and  Networks  (DSN),  the  43rd  Annual  IEEE/IFIP  International  Conference  on.  Budapest,  Hungary,  2013:  1-12. [9]  Angel  S,  Wahby  R  S,  Howald  M,  et  al.  Defending  against  malicious  peripherals  with  Cinch//Proceedings  of  USENIX  Security  Symposium.  Vancouver,  Canada,  2016:  397-414. [10] Hao  Z,  Endong  W,  Yinfeng  W,  et  al.  Transparent  driver-kernel  isolation  with  VMM  intervention//Proceedings  of  the  First  ACM  SIGOPS  Conference  on  Timely  Results  in  Operating  Systems.  Farmington,  USA,  2013:  2. [11] LeVasseur  J,  Uhlig  V,  Stoess  J,  et  al.  Unmodified  Device  Driver Reuse  and  Improved  System  Dependability  via  Virtual  Machines//Proceedings  of  Opearting  Systems  Design  &  Implementation  (OSDI),  the  12th  USENIX  Symposium  on.  San  Francisco,  USA,  2004:  17-30. [12] Sumpf  S,  Brakensiek  J.  Device  driver  isolation  within  virtualized embedded  platforms//Proceedings  of  Consumer  Communications and  Networking  Conference  (CCNC),  6th  IEEE.  Las  Vegas,  USA,  2009:  1-5. [13] Tan  L,  Chan  E  M,  Farivar  R,  et  al.  iKernel:  Isolating  buggy  and  malicious  device  drivers  using  hardware  virtualization  support//  Proceedings  of  Third  IEEE  International  Symposium  on  Dependable,  Autonomic  and  Secure  Computing  (DASC).  Columbia,  USA,  2007:  134-144. [14] Ning  F,  Weng  C,  Luo  Y.  Virtualization  I/O  optimization  based  on  shared  memory//Proceedings  of  Big  Data,  2013  IEEE  International  Conference  on.  Santa  Clara,  USA,  2013:  70-77. [15] Cam Macdonell,  Xiaodi  Ke,  A  Wolfe  Gordon,  and  Paul  Lu.  2011.  Low-Latency,  High-Bandwidth  Use  Cases  for  Nahanni/ivshmem.  In  KVM  Forum  2011. [16] Patni  S,  George  J,  Lahoti  P,  et  al.  A  zero-copy  fast  channel  for  inter-guest  and  guest-host  communication  using  VirtIO-serial//Proceedings  of  Next  Generation  Computing  Technologies  (NGCT),  the  1st  International  Conference  on.  Dehradun,  India,  2015:  6-9.               余劲等：DBox：  宏内核下各种设备驱动程序的高性能安全盒  17  YU  Jin, born  in  1982,  Ph.  D.  candidate, His  current  research  interests  include operating  system  security,  virtualization and cloud computing.     ZHU  Yu, born  in  1990, M.S. candidate,  His  current  research include system and deep learning security.  HUANG  Hao,  born  in  1957,  Ph.  D.,  professor,  Ph.  D. supervisor.  His  current  research  interests  include  system software and information security.      Xu  Fengyuan,  born  in  1983,  Ph.  D.,  professor,  Ph.  D. supervisor.  His  current  research  interests  include  systems security, edge computing and big-data driven security.    Background This  work  is  mainly  supported  by  the  National  High Technology  Research  Development  Program  (863  Program) of  China  under  grant  No.2011AA01A202  and  the  National Science  Foundation  of  China  under  grant  No.  61321491. They  are  all  related  to  how  to  improve  operating  system security  by  sandbox,  encryption,  virtual  machine introspection and other security technology. In the past years, the  group  have  done  some  interesting  research  in operating-system security including a trusted boot revolution, an  operating  system  kernel  integrity  protection  based  on VMM,  an  operating  system  object  semantics  model  and  its partial  formal  specifications  and  verification,  a  verified lightweight  approach  to  provide  life  time  kernel  integrity surveillance, a security microkernel operating system VTOS, an automatic guest virtual machine system function hook and control program VMSPY. In  monolithic  kernel  based  operating  systems, vulnerabilities of  devices  drivers  are  generally  considered  to be  a  major  and  common  fact  of  a  variety  of  security problems.  During  the  recent  years,  more  and  more  CVE reports  realted  to  it  have  been  submitted.  Due  to  the importance  of  this  issue,  quite  a  few  of  researchers  have delved into this field and a large amount of countermeasures have  been  proposed. But  these  methods  either  focus  on security for the OS kernels at the expense of performance or vice  verse.  In  this  paper,  we  propose a  performace-oriented driver isolation framework, which is called Dbox, based upon virtualization technology and x86 architecture features. Dbox contains a driver box (DDVM) based on VM for the purpose of driver isolation. Compared with the original VM, DDVM is  shipped  with  a  thin  service  layer  to  handle  interactions form/to the outside of VM and DMA. Also, Dbox provides a common  communication  interface  (CCID)  between  the  host kernel  and  DDVM  for  efficient  I/O  requests. Our  method bridge the gap of security and performaces for device drives of monolithic kernels.