v7: https://lore.kernel.org/patchwork/cover/1431031/ On Mon, May 10, 2021 at 5:50 PM Claire Chang <tientzu@xxxxxxxxxxxx> wrote: > > From: Claire Chang <tientzu@xxxxxxxxxx> > > This series implements mitigations for lack of DMA access control on > systems without an IOMMU, which could result in the DMA accessing the > system memory at unexpected times and/or unexpected addresses, possibly > leading to data leakage or corruption. > > For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is > not behind an IOMMU. As PCI-e, by design, gives the device full access to > system memory, a vulnerability in the Wi-Fi firmware could easily escalate > to a full system exploit (remote wifi exploits: [1a], [1b] that shows a > full chain of exploits; [2], [3]). > > To mitigate the security concerns, we introduce restricted DMA. Restricted > DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a > specially allocated region and does memory allocation from the same region. > The feature on its own provides a basic level of protection against the DMA > overwriting buffer contents at unexpected times. However, to protect > against general data leakage and system memory corruption, the system needs > to provide a way to restrict the DMA to a predefined memory region (this is > usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]). > > [1a] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html > [1b] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html > [2] https://blade.tencent.com/en/advisories/qualpwn/ > [3] https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/ > [4] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132 > > v6: > Address the comments in v5 > > v5: > Rebase on latest linux-next > https://lore.kernel.org/patchwork/cover/1416899/ > > v4: > - Fix spinlock bad magic > - Use rmem->name for debugfs entry > - Address the comments in v3 > https://lore.kernel.org/patchwork/cover/1378113/ > > v3: > Using only one reserved memory region for both streaming DMA and memory > allocation. > https://lore.kernel.org/patchwork/cover/1360992/ > > v2: > Building on top of swiotlb. > https://lore.kernel.org/patchwork/cover/1280705/ > > v1: > Using dma_map_ops. > https://lore.kernel.org/patchwork/cover/1271660/ > *** BLURB HERE *** > > Claire Chang (15): > swiotlb: Refactor swiotlb init functions > swiotlb: Refactor swiotlb_create_debugfs > swiotlb: Add DMA_RESTRICTED_POOL > swiotlb: Add restricted DMA pool initialization > swiotlb: Add a new get_io_tlb_mem getter > swiotlb: Update is_swiotlb_buffer to add a struct device argument > swiotlb: Update is_swiotlb_active to add a struct device argument > swiotlb: Bounce data from/to restricted DMA pool if available > swiotlb: Move alloc_size to find_slots > swiotlb: Refactor swiotlb_tbl_unmap_single > dma-direct: Add a new wrapper __dma_direct_free_pages() > swiotlb: Add restricted DMA alloc/free support. > dma-direct: Allocate memory from restricted DMA pool if available > dt-bindings: of: Add restricted DMA pool > of: Add plumbing for restricted DMA pool > > .../reserved-memory/reserved-memory.txt | 27 ++ > drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +- > drivers/iommu/dma-iommu.c | 12 +- > drivers/of/address.c | 25 ++ > drivers/of/device.c | 3 + > drivers/of/of_private.h | 5 + > drivers/pci/xen-pcifront.c | 2 +- > drivers/xen/swiotlb-xen.c | 2 +- > include/linux/device.h | 4 + > include/linux/swiotlb.h | 41 ++- > kernel/dma/Kconfig | 14 + > kernel/dma/direct.c | 63 +++-- > kernel/dma/direct.h | 9 +- > kernel/dma/swiotlb.c | 242 +++++++++++++----- > 15 files changed, 356 insertions(+), 97 deletions(-) > > -- > 2.31.1.607.g51e8a6a459-goog >
