LWN：利用debounce buffer来阻止恶意设备利用DMA窃取信息

Bounce buffers for untrusted devices

April 26, 2019,  This article was contributed by Marta Rybczyńska

题图来自： Photo by  Josh Sorenson  from  Pexels

前段时间介绍过Thunderbolt的漏洞，这个问题在社区里又掀起了一次讨论，关于如何保护kernel来避免不可信的热插拔设备的攻击。这个名为Thunderclap的漏洞在此前的公众号文章中已经详细介绍过，恶意设备在插到Thunderbolt接口上可以利用IOMMU的地址映射限制来访问不该能访问到的system memory区域。一个例子就是用USB-C接口的外接设备。此前我们也看到不少其他USB设备发起的攻击。PCI设备也能发起类似攻击。阻止这种攻击的方法之一就是确保IOMMU能实现完整，禁止外设访问与它无关的memory地址。Lu Baolu就提出了一组patch来利用bounce buffer来进行不可信设备的访问。

PCI and untrusted devices

PCI设备通常是插在机箱内部的，一般人都认为它们是可信设备（其实LWN上一位读者就提出了peer-to-peer PCI access的安全性问题）。PCI bus虽然支持hotplug热插拔，其实很少有人用。不过，外置PCI设备是可以通过Thunderbolt接口来接入系统的，这样就可能受到Thunderclap攻击：恶意设备就能利用系统对PCI设备的信任来进行攻击。

PCI bus（总线）对system memory的访问其实还是受限的，因为很多系统都打开了IOMMU。这样device对特定memory取件的访问就受到合理的管控，bus address也就能IOMMU被映射成为某个physical memory address（物理地址）。IOMMU是以page为单位来进行管控的，并且remaped region必须先显式的map之后，才能访问。每个设备也都被分配了不同的address区间。这些措施都非常有效。

不过，不是所有的system都打开了IOMMU，因为IOMMU也会导致performance drop，有些功能也无法跟IOMMU并存。在这种情况下要想改善安全性，核心是怎样能区分开可信设备和不可信设备，2018年12月有个patch在实现这个功能，主要是通过在struct pci_dev里添加一个untrusted flag，这样PCI framework software可以针对这类设备做一些特殊操作，例如打开完整的IOMMU和bounce buffer等。什么样的PCI设备会被标记为untrsuted呢？很简单，只要它的firmware里面把自己的root port标记为external（目前来说就是ExternalFacingPortACPI property），就当做untrusted，这样对Thunderbolt影响到的PCI设备就足够解决问题了。

IOMMU constraints

可信PCI设备通常会用DMA来从system memory区间搬移数据，它们不会越界去访问其他memory zone。对这些可信设备，IOMMU配置的时候就可以特殊处理一下，例如可以给这个硬件多映射一些memory，也能优化IOMMU的利用率。对不可信设备来说就不可以这么假设了，需要严格精确的配置IOMMU。不幸的是，在Intel平台上的IOMMU，最小控制粒度是4KB，哪怕只想让它多访问1个byte，最终IOMMU配置下来，就会让它多访问整个4KB page。

驱动程序如果没有意识到这一点，它只分配了一个很小的buffer，然后通过IOMMU映射后提供给DMA使用，此时的DMA其实就能访问到这个完整的page（可能存放了其他驱动程序或者kernel数据）。DMA API发起这类访问的时候也不会报错，这其实是它的一个缺陷。总之说明就算打开了IOMMU也有风险，系统还需要负责保证不能把其他不相干的数据放到IOMMU映射的page上。

Bounce buffers

终于讲到正题了。最终的解决方案为这些不可信设备实现了bounce buffer。bounce buffer很简单，就是一块单独的memory区间，专门用于DMA操作。Data会被从original buffer复制（"bounced"）到bounce buffer，这块bounce buffer因为是在一块独立的memory区间，因此DMA不可能访问到original buffer周围的系统数据了。

如果original buffer是好几个完整的page，那么就不需要利用bounce buffer，可以直接进行DMA传输，不会泄露不相干数据的。如果original buffer没有落在page边界上，那就需要经过bounce buffer来中转一下再进行DMA访问。DMA的mapping, unmapping, sync操作都会把数据从origianl buffer复制到bounce buffer，反之也是一样。这样IOMMU就直接用bounce-buffer地址来做device DMA传输了，不再是用original buffer。

在I/O操作发起的时候，original I/O buffer会被分为3类：“low”，“middle”，“high”。low和high专指buffer的第一个和最后一个page，如果buffer起始地址不是page align的，它们就会包含其他的不想干数据。而middle pages就是完整的多个page，不需要利用bounce buffer来中转。只有Low和high这两个page可能需要用bounce buffer。这样，一个连续buffer的传输可能会被分割成3部分，不过在IOMMU映射之后，在device看来又像是一个连续buffer了。

Bounce-buffer patch还做了一个修改，在unmap之后，它需要立刻invalidate IOMMU mapping。因为如果IOMMU仍然保存了这个mapping的话，后续这个mapped page被挪作它用的时候，设备可能仍然能访问到这个page，这也会泄露信息。此外，也提供了一个option来关闭bounce buffer，毕竟如果系统管理员能确认插入的设备都是100%可信的，那就没必要引入bounce buffer来影响性能了。

Similarity to swiotlb

在这组patch的讨论过程中，Christoph Hellwig觉得这个方案很像swiotlb（software input output translation lookaside buffer）。swiotbl也是一个bounce-buffer方案，主要是帮助一些无法访问到全部system memory的device来做任意地址的DMA操作。此后patch作者Lu也试了一下能否利用swiotlb的代码来实现，不过最终失败了，因为swiotlb里面提供的low page地址跟原始地址不一致。核心原因是swiotlb会把整个buffer都copy走，而不是仅仅copy low&high这两个page。Robin Murphy建议应该把IOMMU子系统的这类操作都实现的更加通用一些，而不是只为Intel VT-d系统做一个方案。Lu就提交了第二版的改动，是实现了swiotlb的一个扩展。在4月21日提出的这版patch里面包含了对swiotlb的refactoring（重构），以及把一些驱动程序特有的代码搬到了通用的IOMMU模块。

Next steps

利用bounce buffer确实可以保护这一类的攻击。目前还不确定kernel里面是否还有其他类似问题需要来加固in-kernel interface。目前攻击方案已经演进得跟几年前大不一样了，攻击者能够控制各种设备，而此前开发者都认为这些设备是可信的。今后，我没回看到越来越多的恶意设备来通过稀奇古怪的方式攻击我们的系统。过去我们认为完全是kernel内部使用的interface，今后也可能慢慢暴露出问题，从而需要更多加固。

IOMMU bounce buffer的方案已经实现好了，大家都想知道performance penalty有多少。目前测试数据还没有提出来，根据patch描述，performance impact应该很小。至少要比swiotlb小，因为只copy了很少的数据。而大块数据的传输应该都不会受到影响，因为这些buffer一般都是page-aligned。所以只有对小buffer的传输有影响，会引入很多小buffer的copy。

所以在patchset被merge之前，还有不少工作要做（performance data，回答大家的一些comments）。不过很可能用不了多久了，Linux system对于这些untrustworthy设备就能有一个更高级的保护方案了。