lkml.org 
[lkml]   [2021]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[PATCH v4 00/14] Restricted DMA
    Date
    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

    Claire Chang (14):
    swiotlb: Remove external access to io_tlb_start
    swiotlb: Move is_swiotlb_buffer() to swiotlb.c
    swiotlb: Add struct swiotlb
    swiotlb: Refactor swiotlb_late_init_with_tbl
    swiotlb: Add DMA_RESTRICTED_POOL
    swiotlb: Add restricted DMA pool
    swiotlb: Update swiotlb API to gain a struct device argument
    swiotlb: Use restricted DMA pool if available
    swiotlb: Refactor swiotlb_tbl_{map,unmap}_single
    dma-direct: Add a new wrapper __dma_direct_free_pages()
    swiotlb: Add is_dev_swiotlb_force()
    swiotlb: Add restricted DMA alloc/free support.
    dt-bindings: of: Add restricted DMA pool
    of: Add plumbing for restricted DMA pool

    .../reserved-memory/reserved-memory.txt | 24 +
    arch/powerpc/platforms/pseries/svm.c | 4 +-
    drivers/iommu/dma-iommu.c | 12 +-
    drivers/of/address.c | 25 +
    drivers/of/device.c | 3 +
    drivers/of/of_private.h | 5 +
    drivers/xen/swiotlb-xen.c | 4 +-
    include/linux/device.h | 4 +
    include/linux/swiotlb.h | 32 +-
    kernel/dma/Kconfig | 14 +
    kernel/dma/direct.c | 51 +-
    kernel/dma/direct.h | 8 +-
    kernel/dma/swiotlb.c | 636 ++++++++++++------
    13 files changed, 582 insertions(+), 240 deletions(-)

    --

    v4:
    - Fix spinlock bad magic
    - Use rmem->name for debugfs entry
    - Address the comments in v3

    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/

    2.30.0.478.g8a0d178c01-goog

    \
     
     \ /
      Last update: 2021-02-09 07:25    [W:4.119 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site