Google Volleys Latest "Restricted DMA" Patches For Protecting IOMMU-Less Hardware
The past few months there has been work by Google's Chrome OS engineers on Restricted DMA functionality for the Linux kernel to protect systems lacking an IOMMU.
For systems lacking an Input-Output Memory Management Unit (IOMMU), Restricted DMA aims to increase system security by ensuring that no unexpected direct memory access occurs that could lead to data leakage or corruption. From Google's perspective one use-case is PCIe-based WiFi where the PCI Express bus isn't behind an IOMMU. Restricted DMA would help fend off the possibility that problematic WiFi firmware could escalate into a full system exploit.
Restricted DMA uses the SWIOTLB (Software Input Output Translation Lookaside Buffer) for bouncing streaming DMA in/out of a specially allocated memory region and does the memory allocation from that same region. For better protection though the system still needs a way to lock down the memory access such as via a MPU.
Sent out this morning were the v5 patches of Restricted DMA and it appears the work is now settled down. This latest spin is simply re-basing the code against the current Linux-Next state with no functionality changes compared to the prior revision. So it's looking like at this stage the Restricted DMA work might be settled down and could soon end up in mainline with a forthcoming merge window should no other issues arise.
For systems lacking an Input-Output Memory Management Unit (IOMMU), Restricted DMA aims to increase system security by ensuring that no unexpected direct memory access occurs that could lead to data leakage or corruption. From Google's perspective one use-case is PCIe-based WiFi where the PCI Express bus isn't behind an IOMMU. Restricted DMA would help fend off the possibility that problematic WiFi firmware could escalate into a full system exploit.
Restricted DMA uses the SWIOTLB (Software Input Output Translation Lookaside Buffer) for bouncing streaming DMA in/out of a specially allocated memory region and does the memory allocation from that same region. For better protection though the system still needs a way to lock down the memory access such as via a MPU.
Sent out this morning were the v5 patches of Restricted DMA and it appears the work is now settled down. This latest spin is simply re-basing the code against the current Linux-Next state with no functionality changes compared to the prior revision. So it's looking like at this stage the Restricted DMA work might be settled down and could soon end up in mainline with a forthcoming merge window should no other issues arise.
1 Comment