linux-kernel - Re: [PATCH v1 1/1] ARM: Select DMA_DIRECT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+-6iNyj2ZuosbeNb2kB=BXh6XjW=VKS37CVK0uh4YFvLVHBFg@mail.gmail.com>
Date:   Mon, 2 Oct 2023 08:33:08 -0400
From:   Jim Quinlan <james.quinlan@...adcom.com>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Christoph Hellwig <hch@....de>,
        bcm-kernel-feedback-list@...adcom.com, jim2101024@...il.com,
        Russell King <linux@...linux.org.uk>,
        Arnd Bergmann <arnd@...db.de>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Sebastian Reichel <sebastian.reichel@...labora.com>,
        "Mike Rapoport (IBM)" <rppt@...nel.org>,
        Eric DeVolder <eric.devolder@...cle.com>,
        Nathan Chancellor <nathan@...nel.org>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        "moderated list:ARM PORT" <linux-arm-kernel@...ts.infradead.org>,
        open list <linux-kernel@...r.kernel.org>,
        Claire Chang <tientzu@...omium.org>
Subject: Re: [PATCH v1 1/1] ARM: Select DMA_DIRECT_REMAP to fix restricted DMA

On Thu, Sep 28, 2023 at 11:47 AM Robin Murphy <robin.murphy@....com> wrote:
>
> On 28/09/2023 1:07 pm, Jim Quinlan wrote:
> > On Wed, Sep 27, 2023 at 7:10 PM Linus Walleij <linus.walleij@...aro.org> wrote:
> >>
> >> Hi Jim,
> >>
> >> thanks for your patch!
> >>
> >> On Tue, Sep 26, 2023 at 7:52 PM Jim Quinlan <james.quinlan@...adcom.com> wrote:
> >>
> >>> Without this commit, the use of dma_alloc_coherent() while
> >>> using CONFIG_DMA_RESTRICTED_POOL=y breaks devices from working.
> >>> For example, the common Wifi 7260 chip (iwlwifi) works fine
> >>> on arm64 with restricted memory but not on arm, unless this
> >>> commit is applied.
> >>>
> >>> Signed-off-by: Jim Quinlan <james.quinlan@...adcom.com>
> >>
> >> (...)
> >>> +       select DMA_DIRECT_REMAP
> >>
> >> Christoph invented that symbol so he can certainly
> >> explain what is missing to use this on ARM.
> >>
> >> This looks weird to me, because:
> >>> git grep atomic_pool_init
> >> arch/arm/mm/dma-mapping.c:static int __init atomic_pool_init(void)
> >> kernel/dma/pool.c:static int __init dma_atomic_pool_init(void)
> >>
> >> Now you have two atomic DMA pools in the kernel,
> >> and a lot more than that is duplicated. I'm amazed that it
> >> compiles at all.
> >>
> >> Clearly if you want to do this, surely the ARM-specific
> >> arch/arm/mm/dma-mapping.c and arch/arm/mm/dma-mapping-nommu.c
> >> needs to be removed at the same time?
> >>
> >> However I don't think it's that simple, because Christoph would surely
> >> had done this a long time ago if it was that simple.
> >
> > Hello Linus,
> >
> > Yes, this is the reason I used "RFC" as the fix looked too easy to be viable :-)
> > I debugged it enough to see that the host driver's
> > writes to the dma_alloc_coherent() region  were not appearing in
> > memory, and that
> > led me to DMA_DIRECT_REMAP.
>
> Oh, another thing - the restricted-dma-pool is really only for streaming
> DMA - IIRC there can be cases where the emergency fallback of trying to
> allocate out of the bounce buffer won't work properly. Are you also
> using an additional shared-dma-pool carveout to satisfy the coherent
> allocations, per the DT binding?

Hello Robin,
Sorry for the delay.  We use "restricted DMA" as a poor person's IOMMU; we can
restrict the DMA memory of a device to a narrow region, and our memory
bus HW has
"checkers' to enforce said region for a specific memory client, e.g. PCIe.

We can confirm the assignment of restricted DMA in the bootlog when the device
is probed:

        iwlwifi 0001:01:00.0: assigned reserved memory node pcieSR1@...00000
        iwlwifi 0001:01:00.0: enabling device (0000 -> 0002)

As far as your other question, why don't I  just post our relevant DT [1].

Regards,
Jim Quinlan
Broardcom STB/CM

[1]
memory {
        device_type = "memory";
        reg = <0x0 0x40000000 0x1 0x0>;
};

reserved-memory {
        #address-cells = <0x2>;
        #size-cells = <0x2>;
        ranges;
        /* ... */

        pcieSR1@...00000 {
                linux,phandle = <0x2a>;
                phandle = <0x2a>;
                compatible = "restricted-dma-pool";
                reserved-names = "pcieSR1";
                reg = <0x0 0x4a000000 0x0 0x2400000>;
        };
};
pcie@...0000 {
        /* ... */
        pci@0,0 {
                /* ... */
                pci-ep@0,0 {
                        memory-region = <0x2a>;
                        reg = <0x10000 0x0 0x0 0x0 0x0>;
                };
        };
};




>
> Thanks,
> Robin.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4210 bytes)