文章目录

abstract
1.Introduction
2.Problem Overview
3.System Design
- 3.1 System overview
- 3.2 Paging Delegation
- - 3.2.1 SecPod Address Space Layout
  - 3.2.2 Secure and Efficient Context Switch
  - 3.2.3 Page Table Update and Validation
- 3.3 Execution Trapping
4.Implementation
- 4.1 Paging Delegation
- 4.2 Security Tool Case Study
5.Evaluation
- 5.1 Security analysis
- - Memory isolation violation
  - Instruction misuse
  - Synthetic attack
- 5.2 Performance Evaluation
- - 5.2.1 Micro-benchmarks
  - 5.2.2 Application Benchmarks
6.Related Work
- Virtualization-based Security
- Kernel/User Application Security
7.Summary

论文：SecPod: A Framework for Virtualization-based Security Systems

链接：https://www.usenix.org/conference/atc15/technical-session/presentation/wang-xiaoguang

会议：usenix security 2015

abstract

页表没有从脆弱的内核中隔离出来

=> 导致内存保护需要监视guest页表的每次更新，这和硬件虚拟化支持的最新进展相冲突

=> 提出SecPod：一个基于虚拟化的安全系统的可扩展框架，它可以提供强大的隔离和与现代硬件兼容。

SecPod的两个关键技术：

paging delegation: 将分页委托给安全空间
executeion trapping: 截获企图滥用特权指令来推翻SecPod的内核尝试

目前已经实现了基于KVM的SecPod的原型

1.Introduction

目前内核内置的防止攻击措施：ASLR、DEP，但是建立在页表在内核中始终可写的基础上，这就导致可以通过操作页表来绕过防护

=> 在虚拟化环境中部署内存和其他保护措施

Patagonix扩展hypervisor来识别和保护运行在VM中的代码
NICKLE使用memory shadowing

基于虚拟化的安全系统通常与硬件虚拟化支持的最新进展不一致

许多安全工具需要拦截和响应虚拟机中的关键事件，每个截获的事件都会导致VM和hypervisor之间的一个或多个高代价的world switches。这和AMD-V和Intel VT努力减少world switches冲突
嵌套分页允许guest在不涉及hypervisor的情况下自由地更新页表，这就迫使hypervisor运行在低效的影子分页模式下来对guest的页表的更新进行捕获和验证

Secpod将一个安全工具封装在一个可信的执行环境中，该环境与易受攻击的内核共存，但又与之严格隔离。

创建一个专用的地址空间（安全空间），与现有的内核地址空间（普通空间）并行。
paging delegation: 内核将其所有分页操作（包括页表及其更新）委托给安全空间，内核被剥夺了直接修改有效页表的特权，安全空间通过审查guest页表更新来实施一个不可绕过的内存隔离
execution trapping: 阻止攻击者通过滥用特权指令破坏安全空间的企图，hypervisor通过信号通知安全空间任何此类尝试，安全空间可以发出警报或终止VM来响应事件。

Secpod可以集成到现有的hypervisor中，只需对其代码库进行最小的增加

SecPod的高效性

I/O-intensive SysBench FileIO benchmark大约3%开销
SysBench online database transaction benchmark大约5%开销

2.Problem Overview

概述硬件虚拟化支持，特别是内存虚拟化支持，并解释他们如何影响安全工具的设计

早期x86的hypervisor使用影子分页SPT来虚拟化guest内存

=> GPT被SPT取代，hypervisor为每个GPT分配一个SPT

=> 对GPT的任何修改必须同步到其对应的SPT才能生效

=> 这为安全工具提供了检查和控制GPT每次更改的机会

影子分页模式下的地址转换，如下图

GPT将guest虚拟地址转换为guest物理地址；guest物理地址需要经过进一步转换为内存控制器使用的实际物理地址

而SPT是唯一有效的页表，他们直接从guest虚拟地址映射到物理地址

早期的扩展侧重于捕获敏感的guest指令，比如SGDT,SIDT,MOV to CR3，以此允许hypervisor虚拟化相关资源。

后来的修订旨在通过关键虚拟化任务的直接支持来改进性能

现在的x86处理器有硬件虚拟化支持，嵌套分页是对内存虚拟化的硬件支持，处理器通过两级页表转换guest的内存访问
- GPT: guest虚拟地址=>guest物理地址
- NPT: guest物理地址=>物理地址

guest有对它自己的GPT的完全控制权，而hypervisor管理NPT，并且NPT并不知道GPT的更改。因此可以通过重新映射GPT中受保护的guest虚拟内存来规避NPT中实施的内存保护。

比如在NPT中实行的DEP保护就可以通过重新映射guest内核代码到可写可执行的物理内存来挫败。

威胁模型

使用可信引导协议如tboot来加载hypervisor，进一步加载guestOS和初始化SecPod。guest内核是良性的但有可利用漏洞。启动完成后假设存在攻击者可以利用漏洞更改内核任意内存。假定hypervisor是可信的。

3.System Design

3.1 System overview

SecPod旨在为基于虚拟化的安全工具提供一个可信的执行环境，如下图是SecPod的两个关键技术图示

安全工具运行在SecPod定义的专门的Secure Space中；内核运行在内核页定义的Normal Space中
Entry Gate和Exit Gate负责切换两个空间，本质上是页表隔离。切换的过程就是将各自的下一个页表加载到CR3（x86页表基址寄存器）中。通过execution trapping保证entry gate是从normal space进入secure space的唯一途径
SecPod中的安全工具可以内省甚至修改内核内存，但不能反过来。单向性

虚拟机自省是指一台虚拟机被赋予hypervisor权限去监视其他虚拟机，可以获取其他虚拟机OS的内存、磁盘和cpu等信息。

libvmi是一个提供了对正在运行的底层虚拟机的运行细节进行监视的c库。

基于简单隔离的页表不安全的三个原因

内核仍然拥有对其页表的完全控制。

这允许（受损的）内核通过映射和修改安全空间内存来绕过Secpod => 需要验证内核的页表更新

=> SecPod使用paging delegation解决：内核将所有的分页操作委托给安全空间，包括页表、页表更新和任务切换。

内核仍然有特权自由地执行特权指令。

这导致一些指令可能被滥用来危害SecPod。比如内核可以使用mov to CR3来加载精心编制地页表来绕过安全空间

=> SecPod使用execution trapping: hypervisor拦截内核执行地敏感特权指令，并将捕获的事件作为信号转发到secure space

=> secure space决定如何响应。比如发出报警、忽略报警、终止违规内核、分派给安全工具

攻击者可以通过DMA攻击挫败SecPod，硬件设备的DMA操作使用物理地址而不被页表转换，因为页表是cpu用来转换内存访问的

hypervisor应该已经使用IOMMU来组织DMA攻击，安全空间也应该从IOMMU中的设备可访问的内存中排除

3.2 Paging Delegation

Secpod将内核的分页操作委托给安全空间，以便强制内存隔离。

secure space维护内核的SPTs，SPTs与内核的页表同步 => 对内核页表的任何更新都必须合并到SPT才能生效，因为SPT是CPU使用的唯一页表。

内核可能保留自己的页表以方便实现，但它们从不加载到CPU以进行地址转换。(类似于传统的虚拟化系统中的影子分页)

在传统虚拟化中，SPTs由hypervisor管理，hypervisor负责将GPT的更新同步到SPTs，SPTs是guest使用的唯一页表。
- SPTs将guest虚拟地址直接转换为物理地址。
在SecPod中，SPTs由in-VM secure space管理，并结合NPTs嵌套页表对guest地址进行转换。
- SPTs: guest virtual address => guest physical address，在大多数情况下，Secpod中的SPT是内核页表的简单副本
- SPTs切换比传统虚拟化更快；保持了嵌套分页的简单和效率
- 影子分页很早就在虚拟化中使用，但第一次在这种体系结构中使用。

为了委托分页相关操作和entry gata，可以用对安全空间中响应的服务的调用来替换内核中的每个分页操作。

在半虚拟化的(PV)VM中运行的内核内置了这些hooks，比如linux内核有pvops框架。对于没有PV接口的内核，通过潜在的补丁以实现类似的接口。

pvops可以在运行时判断它是否在虚拟化的系统中运行，并相应地切换到优化的低级操作。

pvops框架包括几组低级操作，比如pv_time_ops,pv_cpu_ops,pv_mmu_ops,pv_lock_ops，比如可以使用pv_mmu_ops实现也委托

3.2.1 SecPod Address Space Layout

normal space包括了内核空间和用户空间，内核空间在normal space和secure space映射在相同的位置

=> Secpod中的一个安全工具可以访问内核，就像它在内核中运行一样，因为关键的内核数据结构保留在它们假定的位置

=> 这有助于缓解语义鸿沟问题

在secure space中，内核内存被设置为不可执行

=> 防止安全工具执行(不可信的)内核代码

secure space中安全代码和数据被放置在较低地址空间中，因为内核通常位于高地址。

安全代码为安全工具提供了有用的函数库，比如malloc,free,string函数。
安全数据包括阴影页表的存储库和用于该存储库的快速索引的几个基于哈希的数据结构

entry gate和exit gate是唯一的入口和出口

两个gate在normal space和secure space映射到相同的位置

细节处理

一个共享页面=> 两个空间之间传递数据

安全空间从内核分配后，随后将其从内核中移除 => 不会将其用于其他目的

设置写抑或执行在secure space，=> 防止安全工具包含漏洞

部署其他的防护机制对secure space提供更强的保护

3.2.2 Secure and Efficient Context Switch

Secpod实现了基于页表的隔离。要切换空间，需要将下一个空间的页表加载到CR3中。

secure space只有一个页表，即SecPod页表。而normal space每个进程有很多页表。

需要确保上下文切换的安全性和原子性

=> entry gate将内核状态保存到栈，关中断，然后将其页表和堆栈加载到处理器以进入secure space。

=> exit gate执行相反的操作

为了防止内核通过加载巧尽心思构建的页表来破坏安全空间，我们请求虚拟机管理程序拦截并检查guest对CR3的每一次写入。

=> 导致大量的性能开销

=> 利用交CR3 target-list的硬件特性。用CR3 target-list四个页表中的一个加载CR3不会被hypervisor捕获。

以前的系统使用shadow paging来虚拟化guest内存；guest任务切换由hypervisor管理

=> 虽然为更新CR3 target-list提供了方便的机会（CR3 target-list只能被hypervisor更新）

=> 但是阻止这些系统利用嵌套分页

=> SecPod被设计避免了这个问题

理想情况下，guest中的任务切换不应该涉及hypervisor，就像在普通的嵌套分页中一样。但是，guest有许多影子页表，而CR3 target-list只能容纳四个页表根。

entry gate永远不会导致任何VM退出，因为SecPod页表被锁定在列表中；但是如果对于normal space的SPT不在列表中，那exit gate会导致VM退出。

内核和secure space都不能更新CR3 target-list因为他们都运行在guest模式，

=> 解决方案：在secure space中分配一个固定的顶级页表FTLPT，并在任务切换期间将下一个SPT的顶级页表复制给它。

=> SecPod对硬件来说只使用两个页表：FTLPT和SecPod页表。两个都可以被存入CR3 target-list.

=> normal和secure空间合法上下文切换不会被hypervisor捕获。

文章中的原型使用x86的PAE（物理地址扩展）模式，这样顶级页表TLPT包括了四个条目，因此可以快速复制。

大多数linux发行版默认使用PAE模式在内核中，因为NX（non-executable）位仅在此模式下可用

FTLPT是secure space中SPT池中的一部分=> 内核无法访问

不能使用PCID（进程上下文标识符，aka. ASID）来标记TLB，原因如下

TLB在上下文切换时需要刷新，因为FTLPT为许多进程转换地址
PCID设置在CR3寄存器，但是CR3 target-list只能被hypervisor修改

3.2.3 Page Table Update and Validation

内核将分页委托给安全空间，以防止对其页表进行未经授权的修改。将半虚拟化接口pv_mmu_ops将低级分页操作转发给secure space。

当内核需要分配一个新的L3页表时，它将请求发送到安全空间，
安全空间通过从SPT池中分配一个空白的L3页表并将其链接到父影子页表来响应
然后，GPT和SPT之间的映射被记录在哈希表中以用于快速索引
当以后将新的页表条目添加到GPT时，只有在没有发现违反内存保护的情况下，GPT才同步到SPT。（验证器使用几个哈希表进行快速事实检查。）

secure space完全控制内核的内存保护。任何对影子页表的更新都需要被secure space审查。默认下，secure space强制normal/secure空间隔离和对内核的写抑或执行。

normal/secure space隔离

此策略防止(不守信的)内核操纵secure空间内存。

内核被禁止映射到任何安全空间内存，除了entry和exit gate。

对于每个更改影子页表的操作，SecPod检查物理页是否属于安全空间和虚拟地址是否有两个gate（一个代码页和一个数据页）重叠。如果任一测试是true，则拒绝更新。这样做内核就不能映射安全空间内存和改变gates。

kernel 写抑或执行

以前基于虚拟化的系统利用hypervisor中的影子分页来保护内核完整性。 Secpod在VM中提供了相同级别的保护。

使用基于模板的方法实施写抑或执行。现在的内核部署了写抑或执行，初始内核页表可以作为内核内存保护的模板。=> 对于内核映射的每次更新，Secpod只需要将新的内存保护与模板进行比较。

SecPod不从外部解决内核写抑或执行本身的不足

强制安全空间的写抑或执行使得更难绕过。此外，关键的内核数据结构，如系统调用表，也对其虚拟地址和物理内容进行写保护

3.3 Execution Trapping

在SecPod中，内核仍然有执行关键系统指令必要的特权=>如果没有约束，此特权可能被滥用来破坏安全空间。例如通过加载恶意页表甚至禁用分页。=>有必要控制客户执行的指令。

简单地在内核中禁止这些指令行不通。因为x86有可变指令长度，而且一些“无意的”指令可以从合法指令中创建。

以前的软件故障隔离系统通过编译器或二进制转换删除无意的指令
SecPod中将虚拟化硬件配置为捕获这些指令，无论他们是良性的还是“无意的”，比如LGDT,LLDT,LIDT,LMSW,MOV TO CR0

截取这些指令不会造成很大的性能开销，因为大多数指令在内核初始化后并不经常执行。

注意Secpod不仅保护这些寄存器，还保护相关的数据结构，如全局描述符表和中断描述符表

hypervisor截获guest执行的敏感指令后，它将事件通知安全空间，这和传统OS的信号传递类似

两者都实现向上调用，只是信号从内核传到用户进程，而SecPod中的事件从hypervisor传递到secure space。

当指令被截获时

hypervisor保存当前虚拟cpu状态到虚拟机控制块VMCB，并将保存的寄存器拷贝到entry gate的数据页来提供违法指令的上下文。
然后hypervisor将VMCB中保存的指令指针更新到entry gate，并返回给guest
cpu从VMCB回复guest状态，并继续执行到entry gate
secure space识别这是来自hypervisor的向上调用并相应处理

4.Implementation

部署的SecPod原型宿主机和客户机都是linux，在hypervisor添加100多行源码来设置CR3 target-list并捕获敏感指令的执行。在客户机内核添加800行源码来实现分页委托。安全空间有2300行源码。

4.1 Paging Delegation

在SecPod中，guest内核将其分页操作委托给安全空间，这使后者能够完全控制客户机的内存映射和保护。

使用pvops接口向安全空间转发分页请求

pvops接口源于Xen项目为了创建一个通用的半虚拟化内核而出现的接口，此内核可以适应不同的hypervisor以及本地的非虚拟化平台。PVOPS将关键的半虚拟化操作分成几个结构，pv_time_ops,。pv_cpu_ops，pv_mmu_ops，pv_lock_ops，pv_irq_ops和代替PV的操作。比如原生的x86系统使用mov to cr3加载页表，而pvops使用pv_mmu_ops->write_cr3。

pv_mmu_ops具有secpod将分页委托给安全空间所需的所有功能，比如write_cr3,set_pte,set_pmd,flush_tlb_kernel等。

=> 只需要借助安全空间提供的相关服务来实现pv_mmu_ops所需要的功能。

这本质上创建了一个只有MMU的半虚拟化平台，因为其他的PV操作和本机平台相同。

pvops通过对pv_xxx_ops结构体间接的调用来代替本地低层硬件操作，这给本机系统带来了一些较小但可测量的性能开销，因为内核经常使用其中的一些功能。

因为一些函数在初始化后保持不变，为了性能考虑，通过直接调用相应的本机函数，甚至额你连简单操作如write_cr3来专门化每个间接pvops调用。

=>需要在专门化之前替换pv_mmu_ops中的函数指针。

=>专用化后对pv_mmu_ops结构的更改将不会生效，为此修改了内核源代码，以便在启动过程的早期设置pv_mmu_ops结构

因为安全空间尚未初始化，所以文章使用一个临时页表作为内核内的“影子页表”，并向其提交页表更新。临时页表必须静态分配，因为内核内存分配器也没有初始化。在安全空间准备好运行后，我们将临时页表复制到安全空间中的影子页表。

文章的客户内核本质上是一个带有半虚拟化MMU的本地内核。在早期引导阶段拦截MMU操作，但是在此之前创建的任何页表都必须手动复制到安全空间。

比如swapper_pg_dir在内核中静态分配，并作为内核地址空间的master页表。linux中每个进程都有自己用户空间内存的映射，但共享从swapper_pg_dir拷贝来的相同的内核部分。除了空闲任务外没有其他进程使用swapper_pg_dir进行地址转换。如果swapper_pg_dir是第一次加载到CR3，只需为他床加你个新的影子页表。

SecPod提供entry和exit gate给正常空间调用安全空间的服务。因为这些gate是两个空间之间唯一的共享代码，上下文切换必须通过它们。这些gate的实现细节和SIM相似。

entry gate首先将当前cpu状态保存到栈，并用cli指令关中断
然后将SecPod页表加载到CR3来进入安全空间
entry gate必须再执行一次cli在安全空间里，来防止不受信的内核跳过第一条cli指令。(如果跳过第一条CLI指令，则在安全空间中发生的中断将停止（虚拟）处理器，因为中断处理程序在安全空间中不可执行，从而导致拒绝服务攻击。)
最后，入口门将安全堆栈加载到堆栈指针（ESP寄存器）并调用服务处理程序。

exit gate以相反的顺序执行相反的操作以返回正常空间。

细节：用NOP指令填充入口和出口门周围未使用的空间，以避免意外指令超出随机字节

在关于TLB（传输查找缓冲区）的entry和exit gate的实现中有一个细节问题。

TLB是虚拟地址到物理地址转换的快速缓存。

为了访问内存，CPU首先在TLB中搜索匹配的虚拟地址。如果在TLB中找到匹配（TLB命中），则将得到的物理地址发送到存储器单元以访问数据。如果TLB没有缓存映射（TLB未命中），CPU将遍历页表以转换地址，并将结果保存在TLB条目中以供将来参考。

=>因此TLB最终决定内存的可访问性。

简单地重新加载一个新页表并不能保证TLB包含新的地址转换。<==因为在上下文切换期间，全局页不会从TLB中刷新（每次加载页表时，都会刷新非全局页,刷新用户空间的所有TLB条目的一种方法是简单地重新加载当前页表）。

Linux内核将其内核页面设置为Global，<==因为所有进程共享相同的内核内存映射。=> 因此在任务切换期间没有必要从TLB中刷新内核映射。

注意，无论PCID设置如何，都可以访问全局页。因此，使用PCID不能解决这个问题。

全局页面可能会在Secpod中造成严重漏洞。

例如，攻击者可以在可执行的全局页Global pages中合成一个函数，该函数加载SecPod页表并操纵安全空间内存

=> 这个函数在进入安全空间后仍然是可执行的，因为它的映射在上下文切换后仍然在TLB中。

=> 另一方面，如果安全空间内存设置为全局，则返回到正常空间后仍可访问。

=> 为了解决这个问题，我们清除了Shadow页表和Secpod页表中的全局位，除了入口和出口门。

=> 这样，在上下文切换之后，TLB将始终包含新的地址映射，避免了前面提到的陷阱。

可以将入口和出口门设置为全局，因为它们的内存受到安全空间的保护，并且它们没有包含足够的用于面向返回的编程的有用小工具

TLB还允许我们批处理页表更新，因为除非用新的转换刷新TLB，否则这些更新将不会生效

=> 因此可以暂时延迟页表更新，直到内核刷新TLB，显式地使用特殊指令或通过任务开关隐式地进行更新。

4.2 Security Tool Case Study

SecPod是基于需牛啊安全工具的可扩展框架，在SecPod中运行的安全工具与易受攻击的内核严格隔离，但仍然可以灵活地查看内核

首先，内核内存在安全空间和正常空间映射相同（但是有不同地保护），=>因此可以在他们原始地位置访问关键内核符号和数据结构
其次，对内核内存映射的任何更改都可以被拦截和调整，<==因为内核将分页委托给安全空间
SecPod还有一个简单的加载器和连接器来动态加载安全工具，类似于内核模块支持

为了展示SecPod框架的灵活性，为SecPod构建了一个安全工具来检测和防止未经授权的内核代码的执行

假设已知良性内核代码的密码散列，这个工具在SecPod中实现相对简单

它为内核页表更新注册了一个回调函数。如果一个新的可执行页在内核中创建，它将验证该页的hash是否属于良性代码页的hash
- yes: 页在影子页表中标记为可执行
- no: 检测到试图执行未经授权的内核代码并引发异常

实现过程中的挑战

当内核模块加载时，内核需要解析调用的内核函数(printk)，并用这些函数的正确偏移量修补模块

=> 这就会导致更改页的哈希值，=> 如果在修改后的代码上计算哈希就会导致误报

=>解决：通过逆向内核模块加载器所作的更改，并基于干净的代码页计算哈希来解决。之后再恢复更改，并验证每个经过修改的函数都是公开的内核函数

此外，还再最近的Intel处理器中使用一个叫supervisor mode execution protectin(SMEP)新特性，来防止内核执行用户代码。

x86体系结构允许内核以内核特权执行用户代码。 SMEP是专门针对这种攻击而设计的。基于软件的防御也可用

这个工具提供了和Patagonix、NICKLE类似的安全保障

这两个系统都基于当时最新的虚拟化技术，分别是带有影子分页的Xen hypervisor和使用动态二进制转换的hypervisor
基于SecPod的实现可以利用嵌套分页

只有在NPT中检测未经授权的代码容易受攻击，除非guest中所有代码都经过授权

=> 否则攻击者可以操纵它完全控制的GPT将内核代码页映射到未经授权的用户代码

5.Evaluation

2.5GHz Intel Core i5 CPU、8GB内存

host: Ubuntu 12.04 LTS、内核版本为3.11.0

guest: 2GB内存、内核版本为3.10.32的Ubuntu 12.04 LTS server

5.1 Security analysis

重点关注内存隔离违规、指令滥用和恶意设备攻击中的前两个。恶意设备可已通过DMA攻击，但可以使用IOMMU防止。

Memory isolation violation

Secpod的一个关键要求是将安全工具与易受攻击的内核严格隔离开来

=> 依托paging delegation和execution trapping

此类攻击试图恶意修改安全空间内存

=> 安全空间没有映射到普通空间（除了entry/exit gate）

=> 攻击者无法直接修改

=> 攻击者必须直接过通过欺骗安全空间将安全空间映射到普通空间，但是在SecPod防止了这两个方法

内核将分页操作委托给安全空间，让内核自己的页表不生效。安全空间的影子页表页不能被受威胁的内核直接访问
内核可能会请求Secpod将安全空间内存映射到普通空间。 Secpod的页表更新验证阻止了这一点，该验证强制执行普通/安全空间隔离。具体地说，它不允许普通空间映射安全空间的任何物理页，并保护入口和出口门的虚拟地址和物理内容。

Instruction misuse

此类攻击通过滥用现有指令来破坏安全空间。

SecPod对内核强制写抑或执行=>不能向内核注入新的代码=> 但是由于缺乏控制流完整性，像ROP这种代码重用攻击成为可能。

此外，内核仍然具有执行特权指令所需的权限

例如，它可以加载允许操纵安全空间的巧尽心思构建的页表。

=> 通过捕获和审查内核对关键指令的执行来解决这类攻击(比如mov to CR3)

=> Secpod确保加载两个合法页表以外的页表将被捕获和拒绝。它还为类似LGDT的指令保护关联的数据结构。

由于内核不能加载任意页表，它可能会尝试在启用中断的情况下进入安全空间。

这可以通过入口门实现，例如，跳过第一个CLI并在第二个CLI之前触发一个中断。然后CPU将在安全空间中执行中断处理程序。

=> 设计可以防止这种攻击，因为中断处理程序不能在CPU切换到安全空间时立即执行

=> 然而，由于不可执行的中断处理程序，这可能会导致虚拟CPU停止。

攻击也可以通过面向返回的编程(ROP)发起。

=> 通常情况下，一旦CPU进入安全空间，内核代码就变得不可执行，ROP程序就无法继续。

然而，有一种微妙的情况，ROP程序在进入安全空间时切换到安全空间中的gadget。通过这样做，程序可以跨上下文切换而继续运行，因为攻击堆栈映射在安全空间中。

这种攻击总体上很难使用，因为安全空间可能没有足够有用的gadgets。还可以通过将现有的ROP防御应用于安全空间来缓解这种情况，例如控制流完整性、代码随机化和系统性移除gadgets。

Synthetic attack

为了进一步验证SecPod的安全性，文章创建了一个合成的内核rootkit，hook了系统调用表来拦截系统调用，如 sys_read 和 sys_mkdir

实验安全工具可以检测恶意rootkit的加载，因为它的哈希不在良性代码页的哈希列表中。

即使没有这个工具，Secpod也可以检测Rootkit修改（只读）系统调用表的企图–Rootkit调用内核函数使系统调用表可写。

此请求被转发到安全空间，随后被拒绝，因为安全空间不允许更改syscall表。

5.2 Performance Evaluation

使用micro-benchmarks和system benchmarks，重复10次取平均结果

micro-benchmarks测量SecPod对细粒度操作（例如系统调用）的影响
system benchmarks测量SecPod整体系统性能

我们将SecPod的性能与由嵌套分页（基线）支持的未修改VM的性能进行了比较；Secpod的VM也有嵌套分页的支持。

因为分页操作委托给安全空间，=> 因此分页操作的效率预计比基线低

5.2.1 Micro-benchmarks

SecPod for LMBench的性能开销，这是一组衡量系统调用性能的基准

文章的原型在大多数系统调用LMBench测试（如 open 、 close 、 signal_install 和 stat ）中的开销不到5%。这些系统调用不包含需要来自安全空间的服务的操作。因此SecPod对这些系统调用的影响很小。

性能下降可能是由测试期间（其他进程的）正常任务切换引起的。
另一方面，涉及页表操作的系统调用受到的影响最大。特别是 fork 的开销最高（52.8%），其次是 exeve 、 mmap 、文件创建和上下文切换（都在17%左右）。这些系统调用大多涉及繁重的页表操作

平均而言，SecPod为LMBench引入了大约10%的性能开销

5.2.2 Application Benchmarks

为了度量Secpod对整个系统性能的影响，我们使用两个基准测试Apachebench和Sysbench进行了实验。

ApacheBench是一个测量系统处理网络流量速度的程序

在VM中运行Apache服务器2.2.22，在另一台具有类似硬件配置的物理机器上运行ApacheBench

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CmNnGCIE-1669277567936)(images/image-20221110102449939.png)]

对于最大为16KB的文件，SecPod的开销小于9%，对于128KB的文件增加到16%，对于256KB的文件则增加到11%

当文件大小增加时，内核需要更频繁地更新页面表，以适应频繁的文件访问，从而导致相对较高的性能开销

ApacheBench的平均性能开销约为9%

SysBench是一套多线程基准测试，用于评估密集工作负载下数据库系统的性能，文章使用其来衡量SecPod 对文件I/O和MySQL处理的影响

两个实验都用许多不同数量的线程重复

在文件I/O实验中使用128个文件（总共1GB）和16KB的块大小来测量吞吐量，开销最大为3.25%

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sbE6HnUX-1669277567937)(images/image-20221110103628834.png)]

还使用SysBench的在线事务处理（OLTP）基准测试来衡量MySQL的性能

构建一个包含1000000个条目的MySQL数据库，并使用不同数量的线程查询数据库

结果如图10所示，性能损失在2%至14%的范围内，平均为5%

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ey2W4RvM-1669277567940)(images/image-20221110103825750.png)]

当线程数超过32时，性能开销就会减少。这可能是因为对共享资源的争用造成的性能损失超过了从那时开始的Secpod。这反映在使用超过32个线程时，每秒处理的事务数减少。

6.Related Work

Virtualization-based Security

第一类相关工作是大量基于虚拟化的安全系统，具有不同的重点，如恶意软件分析、虚拟蜜罐、内核rootkit检测和预防等。特别是，虚拟化经常被应用在虚拟机内省的上下文中。

语义鸿沟是VMI系统面临的主要挑战之一，因为VMI的目标是从VM的原始数据（如内存、磁盘）中语义推断VM内的活动和状态。 Virtuoso可以有效地自动化构建基于内省的安全工具。SIM是最密切相关的系统，它首先利用CR3 target-list从out-of_VM监视in-VM.

SIM是一个监控框架，而SecPod的目标是支持基于虚拟化的通用系统。特别是，SecPod通过结合两种关键技术（分页委托和执行陷阱）为安全工具创建了一个可信的执行环境。此外，SecPod以不同的方式使用CR3目标列表来支持嵌套分页（第3.2.2节）。VMI系统可以与SecPod的代码完整性保证和细粒度页表监控集成，并从中受益。

虚拟化也是增强内核或应用程序安全性的平台的流行选择，

Overshadow的设计是为了保护用户数据的保密性，即使内核完全受损
Patagonix通过基于虚拟化的代码标识来保护内核代码的完整性
HookSafe通过系统的钩子重定向解决了保护粒度问题

大多数这样的系统需要可靠的内核代码完整性。否则，攻击者可以通过注入恶意代码来破坏他们的保护。 Secpod是这些系统的理想平台。 Secpod中的安全工具与易受攻击的内核严格隔离，但仍然具有内核内工具的可见性

作为概念验证，我们实现了一个基于Secpod的安全工具，以防止未经授权的代码在内核中执行。这提供了类似于Patagonix[28]和Nickle[31]的安全保证（第4.2节）。

基于虚拟化的系统，包括SecPod，由于其较小的代码库和攻击面，假定hypervisors是可信的。然而，现代虚拟机监控程序臃肿的代码基础和最近的攻击使这一假设受到质疑最近，通过正式验证、安全增强以及大小缩减和分解，在保护hypervisors完整性方面做出了一系列努力。这些系统可以自然地与SecPod集成，以提供强大的安全基础

Kernel/User Application Security

在内核和用户应用程序安全方面的大量研究

ASLR和DEP内核级别的保护方案存在一个缺陷，即页表不受攻击的保护。SecPod可以为内核强制实施DEP，ASLR和DEP可以通过ROP绕过，

控制流完整性是对大多数控制流攻击（包括ROP）的有效防御，它要求运行时控制流必须遵循程序的控制流图

最近在CFI方面的努力显著提高了其性能和与商用现成应用程序的兼容性。

DEP是CFI的先决条件，

大多数先前的CFI系统将用户程序作为目标，它们依赖内核为代码和只读数据提供必要的内存保护
最近致力于CFI适应内核转向虚拟化以获得基本的支持

KCOFI利用安全的虚拟体系结构来插入软件和硬件交互。

所有软件，包括内核，都编译到SVA的虚拟指令集。

Secpod还支持内核CFI，因为它为安全工具提供了强大的隔离和可靠的内存保护。

先前也有一些实现原件故障隔离CFI方面的工作，SFI旨在限制宿主应用程序中不受信任的代码。

例如，Native Client使用两层沙箱在Web浏览器中安全地运行不受信任的本机插件。 SFI技术被用来隔离内核中不可信的设备驱动程序

7.Summary

介绍了Secpod的设计、实现和评估，Secpod是一个用于基于虚拟化的安全系统的可扩展框架。Secpod为安全工具提供了可信的执行环境

它们不仅与易受攻击的内核严格隔离，而且对内核具有完全可见性。

特别是，对客户机页表的任何更新都可以被这些工具拦截和管理，从而允许对客户机内核的内存保护进行细粒度控制。通过使用虚拟机中的影子分页，Secpod与硬件虚拟化支持的最新进展完全兼容，特别是嵌套分页。

SecPod:基于虚拟化的安全系统框架相关推荐

9个基于Java的搜索引擎框架
9个基于Java的搜索引擎框架转自:http://blog.csdn.net/xiaomin1991222/article/details/50980573 1.Java 全文搜索引擎框架 Luce ...
NET Core微服务之路：自己动手实现Rpc服务框架，基于DotEasy.Rpc服务框架的介绍和集成...
原文:NET Core微服务之路:自己动手实现Rpc服务框架,基于DotEasy.Rpc服务框架的介绍和集成本篇内容属于非实用性(拿来即用)介绍,如对框架设计没兴趣的朋友,请略过. 快一个月没有写博 ...
DL之RetinaNet：基于RetinaNet算法(keras框架)利用resnet50_coco数据集(.h5文件)实现目标检测
DL之RetinaNet:基于RetinaNet算法(keras框架)利用resnet50_coco数据集(.h5文件)实现目标检测相关文章 DL之RetinaNet:RetinaNet算法的简介( ...
twisted：基于python的twisted框架编写一个客户端和服务端的对话聊天空间
twisted:基于python的twisted框架编写一个客户端和服务端的对话聊天空间目录输出结果实现代码输出结果更新-- 实现代码 #基于python的twisted框架编写一个简单的聊 ...
基于asp.net + easyui框架，一步步学习easyui-datagrid——界面（一）
从这篇博客,我会一步步的为大家讲解,easyui框架中最常用的一个控件datagrid.在使用easyui框架时,datagrid是使用最多的控件,它不仅好用,关键是实用. 我为大家建立一个博客更新的 ...
【PC端vue ui框架学习】vue项目如何使用基于vue的UI框架Element
看了下iView之后,顺便看了看同样基于vuejs的ui框架Element,那么在vue项目中应该如何使用Element呢?以下做简单的记录. 官网定义:Element,一套为开发者.设计师和产品经理 ...
【PC端vue ui框架学习】vue项目如何使用基于vue的UI框架iview
今晚看了一下基于vuejs的ui框架iview,感觉UI挺好看的,那么在vue项目中应该如何使用iview呢?以下做简单的记录. 首先安装iview: $ npm install iview --sa ...
[机器学习]AutoML---谷歌开源AdaNet：基于TensorFlow的AutoML框架
谷歌开源了基于 TensorFlow 的轻量级框架 AdaNet,该框架可以使用少量专家干预来自动学习高质量模型.据介绍,AdaNet 在谷歌近期的强化学习和基于进化的 AutoML 的基础上构建,快 ...
javaml_一些基于Java的AI框架：Encog，JavaML，Weka
javaml 在进行编程收集情报工作时,我发现自己花了很多时间将Python代码转换为Java,通常对我的进度缓慢感到不耐烦,所以我一直在寻找替代方法. 我发现3: Encog – Heaton研究 ...

SecPod:基于虚拟化的安全系统框架