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: <20231006074045.GA15303@lst.de>
Date:   Fri, 6 Oct 2023 09:40:45 +0200
From:   Christoph Hellwig <hch@....de>
To:     Jim Quinlan <james.quinlan@...adcom.com>
Cc:     Christoph Hellwig <hch@....de>,
        Linus Walleij <linus.walleij@...aro.org>,
        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>
Subject: Re: [PATCH v1 1/1] ARM: Select DMA_DIRECT_REMAP to fix restricted
 DMA

On Thu, Oct 05, 2023 at 01:53:33PM -0400, Jim Quinlan wrote:
> > Yes, DMA_DIRECT_REMAP should only be used for platforms using the
> > generic generic remap that plus straight into dma-direct and
> > bypasses arch_dma_alloc.
> >
> > ARM first needs support to directly set the uncached/wc bits on
> > the direct mapping for CMA, which should be fairly simple but require
> > wide spread testing.
> >
> > I'd be happy to work with anyone who wants to look into this.
> I'd like to look into this and help make it work for ARCH=arm but you
> seem to be saying that you also need help from ARM the company?

No, I don't care about companies.  I just need someone (singular or
plural) to test a wide range of arm systems.

Here is my idea for the attack plan:

As step 1 ignore the whole CMA direct map issue, and just to the
trivial generic dma remap conversion.  This should involved:

 - select DMA_DIRECT_REMAP
 - provide arch_dma_prep_coherent to flush out all dirty data by
   calling __dma_clear_buffer
 - remove the existing arch_dma_alloc/arch_dma_free and all their
   infrastructure

With this things should work fine on any system not using CMA

Then attack the CMA direct mapping:

 - modify the core DMA mapping code so that the
   ARCH_HAS_DMA_SET_UNCACHED code is only used conditionally
   I'm not quite sure what the right checks and right place is,
   but the intent is that it should allow arm to only use that
   path for CMA allocations.  For all existing users of
   CONFIG_ARCH_HAS_DMA_SET_UNCACHED it should evaluate to
   a compile-time true to not change the behavior or code
   generation
 - then in arm select ARCH_HAS_DMA_SET_UNCACHED and implement
   arch_dma_set_uncached, arch_dma_clear_uncached and the new
   helper above

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ