| Message ID | 20210209062131.2300005-1-tientzu@chromium.org |
|---|---|
| Headers | show |
| Series | Restricted DMA | expand |
On Tue, Feb 09, 2021 at 02:21:18PM +0800, Claire Chang wrote: > This can be dropped if Christoph's swiotlb cleanups are landed. > https://lore.kernel.org/linux-iommu/20210207160934.2955931-1-hch@lst.de/T/#m7124f29b6076d462101fcff6433295157621da09 FYI, I've also started looking into additional cleanups based on your struct in this branch, but I'd like to wait for all the previous changes to settle first: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/swiotlb-struct
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c > index fd9c1bd183ac..8b77fd64199e 100644 > --- a/kernel/dma/swiotlb.c > +++ b/kernel/dma/swiotlb.c > @@ -836,6 +836,40 @@ late_initcall(swiotlb_create_default_debugfs); > #endif > > #ifdef CONFIG_DMA_RESTRICTED_POOL > +struct page *dev_swiotlb_alloc(struct device *dev, size_t size, gfp_t gfp) > +{ > + struct swiotlb *swiotlb; > + phys_addr_t tlb_addr; > + unsigned int index; > + > + /* dev_swiotlb_alloc can be used only in the context which permits sleeping. */ > + if (!dev->dev_swiotlb || !gfpflags_allow_blocking(gfp)) Just noticed that !gfpflags_allow_blocking(gfp) shouldn't be here. Hi Christoph, Do you think I should fix this and rebase on the latest linux-next now? I wonder if there are more factor and clean up coming and I should wait after that. Thanks, Claire
On Fri, Feb 26, 2021 at 12:17:50PM +0800, Claire Chang wrote: > Do you think I should fix this and rebase on the latest linux-next > now? I wonder if there are more factor and clean up coming and I > should wait after that. Here is my preferred plan: 1) wait for my series to support the min alignment in swiotlb to land in Linus tree 2) I'll resend my series with the further swiotlb cleanup and refactoring, which includes a slightly rebased version of your patch to add the io_tlb_mem structure 3) resend your series on top of that as a baseline This is my current WIP tree for 2: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/swiotlb-struct
On Fri, Feb 26, 2021 at 1:17 PM Christoph Hellwig <hch@lst.de> wrote: > > On Fri, Feb 26, 2021 at 12:17:50PM +0800, Claire Chang wrote: > > Do you think I should fix this and rebase on the latest linux-next > > now? I wonder if there are more factor and clean up coming and I > > should wait after that. > > Here is my preferred plan: > > 1) wait for my series to support the min alignment in swiotlb to > land in Linus tree > 2) I'll resend my series with the further swiotlb cleanup and > refactoring, which includes a slightly rebased version of your > patch to add the io_tlb_mem structure > 3) resend your series on top of that as a baseline > > This is my current WIP tree for 2: > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/swiotlb-struct Sounds good to me. Thanks!
v5 here: https://lore.kernel.org/patchwork/cover/1416899/ to rebase onto Christoph's swiotlb cleanups.
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(-)