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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201021051931.GA967331@kroah.com>
Date:   Wed, 21 Oct 2020 07:19:31 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Furquan Shaikh <furquan@...gle.com>
Cc:     linux-kernel@...r.kernel.org,
        Prashant Malani <pmalani@...omium.org>,
        Arthur Heymans <arthur@...ymans.xyz>,
        Patrick Rudolph <patrick.rudolph@...ements.com>,
        Ard Biesheuvel <ardb@...nel.org>, dlaurie@...gle.com
Subject: Re: [PATCH] firmware: gsmi: Drop the use of dma_pool_* API functions

On Tue, Oct 20, 2020 at 10:01:41PM -0700, Furquan Shaikh wrote:
> GSMI driver uses dma_pool_* API functions for buffer allocation
> because it requires that the SMI buffers are allocated within 32-bit
> physical address space. However, this does not work well with IOMMU
> since there is no real device and hence no domain associated with the
> device.
> 
> Since this is not a real device, it does not require any device
> address(IOVA) for the buffer allocations. The only requirement is to
> ensure that the physical address allocated to the buffer is within
> 32-bit physical address space. This change allocates a page using
> `get_zeroed_page()` and passes in GFP_DMA32 flag to ensure that the
> page allocation is done in the DMA32 zone. All the buffer allocation
> requests for gsmi_buf are then satisfed using this pre-allocated page
> for the device.

Are you sure that "GFP_DMA32" really does what you think it does?  A
"normal" call with GFP_KERNEL" will give you memory that is properly
dma-able.

We should not be adding new GFP_DMA* users in the kernel in these days,
just call dma_alloc*() and you should be fine.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ