Securing DMA through Virtualization

problems:

这篇paper发于2012年，当时很多嵌入式设备并没有支持IOMMU，且ARM架构的版本较老，没有支持硬件虚拟化，而很多DMA相关的work并没有关注于DMA攻击，于是本文利用DMA虚拟化方式来保证隔离，防止DMA attack。

contribution:

• 描述了如何使用虚拟化在ARMv5上来保护DMA
• 展示了不需要额外硬件支持的DMA虚拟化
• 对方案进行安全性和性能分析
• 形式化验证*

Related work：

过去的工作都是在嵌入式系统中使用虚拟化，并关注于移植虚拟化层面和性能分析层面。
有人提出了在没有IOMMU时候监控存在的恶意设备驱动程序，但是没有支持多guest，也没有调度相关功能。

Assumptions：

• DMAC是一个通用的DMAC，并且需要CPU对其进行编程，且DMAC接口暴露给hypervisor。
• MMU支持对ARM domains的管理。外设是内存映射的，通过MMU可以控制对它们的访问。
• MMU和DMAC等硬件都是正常工作的，没有恶意。
• Hypervisor和boot loader/BIOS都是可信的。

Threat model

攻击者假设拥有Guest完全的控制权，包括运行代码和获取正常权限的数据，Guest目的是攻击其他guest，修改或者读取code和data，或者阻止其运行code。假设其无法决定DMA是否被其他部分使用，（即无法通过测信道攻击通过延迟时间判断。）

Requirements

• 每次访问DMAC都会陷入hypervisor。
• DMAC只执行符合访问策略的操作。即MMU支持权限的读写。
• guest不能代表其他guest发送DMA请求。
• 调度不会影响安全性。
• hypervisor不能被guest修改。
• DMAC任务要么由DMAC处理，要么进入队列。
• 每个DMA请求都会被处理，处理了之后从DMAC删除。

1-5保证了隔离性，6-7保证了可用性（Availability）。

Design：

设备被映射进内存，于是受MMU控制，于是可以控制拦截与DMAC相关的操作。
DMAC是OVP模拟的，hypervisor是一个别人实现轻量级的。核心就是DMA虚拟化，即模拟DMAC，就是在使用真是DMAC之前，会陷入hypervisor，在模拟DMAC处进行管理转发。

• Shadow Copies and Scheduling：为每个客户模式设置一个DMAC副本，从而防止DMAC设置期间的干扰，当guest需要写入DMAC寄存器时，被hypervisor拦截，然后将其写入shadow DMAC，物理DMAC只接受hypervisor发送过来的数据。然后用一个队列去调度所有的DMA tasks，相应的shadow DMAC中的任务被设置为waiting状态和active状态。
• Trapping with the Data Abort Handler：陷入hypervisor后，data abort handler会对虚拟的DMA请求进行翻译，载入真实的物理DMAC。
• Trapping with the Data Abort Handler：？？直接用MMU相关的权限。
• Handling DMA Interrupts：用以通知DMA已经完成，hypervisor会收到这些interrupts，然后发送给guest。