On Thu, Jan 7, 2021 at 2:48 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
&g= t;
> Hi,
>
> First of all let me say that I am glad that = someone is working on a
> upstream solution for this issue, would app= reciate if you could CC and
> Jim Quinlan on subsequent submissions.<= br>
Sure!

>
>
> On 1/5/21 7:41 PM, Claire Chang wr= ote:
> > This series implements mitigations for lack of DMA access= control on
> > systems without an IOMMU, which could result in th= e DMA accessing the
> > system memory at unexpected times and/or u= nexpected addresses, possibly
> > leading to data leakage or corru= ption.
> >
> > 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 v= ulnerability 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 mitiga= te the security concerns, we introduce restricted DMA. Restricted
> &= gt; 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 lea= kage and system memory corruption, the system needs
> > to provide= a way to restrict the DMA to a predefined memory region (this is
> &= gt; usually done at firmware level, e.g. in ATF on some ARM platforms).
= >
> Can you explain how ATF gets involved and to what extent it do= es help,
> besides enforcing a secure region from the ARM CPU's p= erpsective? Does
> the PCIe root complex not have an IOMMU but can so= mehow be denied access
> to a region that is marked NS=3D0 in the ARM= CPU's MMU? If so, that is
> still some sort of basic protection = that the HW enforces, right?

We nee= d the ATF support for memory MPU (memory protection unit).
Restricted DM= A (with reserved-memory in dts) makes sure the predefined memoryregion is for PCIe DMA only, but we still= need MPU to locks down PCIe access to

that specific regions.

>
> On Broadcom STB So= Cs we have had something similar for a while however
> and while we d= on't have an IOMMU for the PCIe bridge, we do have a a
> basic pr= otection mechanism whereby we can configure a region in DRAM to
> be = PCIe read/write and CPU read/write which then gets used as the PCIe
>= inbound region for the PCIe EP. By default the PCIe bridge is not
> = allowed access to DRAM so we must call into a security agent to allow
&g= t; the PCIe bridge to access the designated DRAM region.
>
> We= have done this using a private CMA area region assigned via Device
>= Tree, assigned with a and requiring the PCIe EP driver to use
> dma_= alloc_from_contiguous() in order to allocate from this device
> priva= te CMA area. The only drawback with that approach is that it
> requir= es knowing how much memory you need up front for buffers and DMA
> de= scriptors that the PCIe EP will need to process. The problem is that
>= ; it requires driver modifications and that does not scale over the number<= br>> of PCIe EP drivers, some we absolutely do not control, but there is= no
> need to bounce buffer. Your approach scales better across PCIe = EP
> drivers however it does require bounce buffering which could be = a
> performance hit.

Only the streaming DMA (map/unmap) needs = bounce buffering.
I also added alloc/free support in this series
(https://lore.kern= el.org/patchwork/patch/1360995/), so dma_direct_alloc() will

try to allocate memory from the pre= defined memory region.

As for the performance hit, it should be simi= lar to the default swiotlb.
Here are my experiment results. Both SoCs la= ck IOMMU for PCIe.

PCIe wifi vht80 throughput -

=C2=A0 MTK So= C =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tcp_tx =C2= =A0 =C2=A0 tcp_rx =C2=A0 =C2=A0udp_tx =C2=A0 udp_rx
=C2=A0 w/o Restricte= d DMA =C2=A0244.1 =C2=A0 =C2=A0 134.66 =C2=A0 312.56 =C2=A0 350.79
=C2= =A0 w/ Restricted DMA =C2=A0 =C2=A0246.95 =C2=A0 136.59 =C2=A0 363.21 =C2= =A0 351.99

=C2=A0 Rockchip SoC =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tc= p_tx =C2=A0 =C2=A0 tcp_rx =C2=A0 =C2=A0udp_tx =C2=A0 udp_rx
=C2=A0 w/o R= estricted DMA =C2=A0237.87 =C2=A0 133.86 =C2=A0 288.28 =C2=A0 361.88
=C2= =A0 w/ Restricted DMA =C2=A0 =C2=A0256.01 =C2=A0 130.95 =C2=A0 292.28 =C2= =A0 353.19

The CPU usage doesn't increase too much either.
Al= though I didn't measure the CPU usage very precisely, it's ~3% with= a single

big core (Corte= x-A72) and ~5% with a single small core (Cortex-A53).

Thanks!
>= ;
> Thanks!