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]
Date:   Mon, 22 Mar 2021 19:44:29 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Alex Elder <elder@...aro.org>, davem@...emloft.net, kuba@...nel.org
Cc:     bjorn.andersson@...aro.org, evgreen@...omium.org,
        cpratapa@...eaurora.org, subashab@...eaurora.org, elder@...nel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] net: ipa: avoid 64-bit modulus

On 3/22/21 6:05 PM, Alex Elder wrote:
> It is possible for a 32 bit x86 build to use a 64 bit DMA address.
> 
> There are two remaining spots where the IPA driver does a modulo
> operation to check alignment of a DMA address, and under certain
> conditions this can lead to a build error on i386 (at least).
> 
> The alignment checks we're doing are for power-of-2 values, and this
> means the lower 32 bits of the DMA address can be used.  This ensures
> both operands to the modulo operator are 32 bits wide.
> 
> Reported-by: Randy Dunlap <rdunlap@...radead.org>
> Signed-off-by: Alex Elder <elder@...aro.org>

Acked-by: Randy Dunlap <rdunlap@...radead.org> # build-tested


Thanks.

> ---
>  drivers/net/ipa/gsi.c       | 11 +++++++----
>  drivers/net/ipa/ipa_table.c |  9 ++++++---
>  2 files changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/ipa/gsi.c b/drivers/net/ipa/gsi.c
> index 7f3e338ca7a72..b6355827bf900 100644
> --- a/drivers/net/ipa/gsi.c
> +++ b/drivers/net/ipa/gsi.c
> @@ -1436,15 +1436,18 @@ static void gsi_evt_ring_rx_update(struct gsi_evt_ring *evt_ring, u32 index)
>  /* Initialize a ring, including allocating DMA memory for its entries */
>  static int gsi_ring_alloc(struct gsi *gsi, struct gsi_ring *ring, u32 count)
>  {
> -	size_t size = count * GSI_RING_ELEMENT_SIZE;
> +	u32 size = count * GSI_RING_ELEMENT_SIZE;
>  	struct device *dev = gsi->dev;
>  	dma_addr_t addr;
>  
> -	/* Hardware requires a 2^n ring size, with alignment equal to size */
> +	/* Hardware requires a 2^n ring size, with alignment equal to size.
> +	 * The size is a power of 2, so we can check alignment using just
> +	 * the bottom 32 bits for a DMA address of any size.
> +	 */
>  	ring->virt = dma_alloc_coherent(dev, size, &addr, GFP_KERNEL);
> -	if (ring->virt && addr % size) {
> +	if (ring->virt && lower_32_bits(addr) % size) {
>  		dma_free_coherent(dev, size, ring->virt, addr);
> -		dev_err(dev, "unable to alloc 0x%zx-aligned ring buffer\n",
> +		dev_err(dev, "unable to alloc 0x%x-aligned ring buffer\n",
>  			size);
>  		return -EINVAL;	/* Not a good error value, but distinct */
>  	} else if (!ring->virt) {
> diff --git a/drivers/net/ipa/ipa_table.c b/drivers/net/ipa/ipa_table.c
> index 988f2c2886b95..4236a50ff03ae 100644
> --- a/drivers/net/ipa/ipa_table.c
> +++ b/drivers/net/ipa/ipa_table.c
> @@ -658,10 +658,13 @@ int ipa_table_init(struct ipa *ipa)
>  		return -ENOMEM;
>  
>  	/* We put the "zero rule" at the base of our table area.  The IPA
> -	 * hardware requires rules to be aligned on a 128-byte boundary.
> -	 * Make sure the allocation satisfies this constraint.
> +	 * hardware requires route and filter table rules to be aligned
> +	 * on a 128-byte boundary.  As long as the alignment constraint
> +	 * is a power of 2, we can check alignment using just the bottom
> +	 * 32 bits for a DMA address of any size.
>  	 */
> -	if (addr % IPA_TABLE_ALIGN) {
> +	BUILD_BUG_ON(!is_power_of_2(IPA_TABLE_ALIGN));
> +	if (lower_32_bits(addr) % IPA_TABLE_ALIGN) {
>  		dev_err(dev, "table address %pad not %u-byte aligned\n",
>  			&addr, IPA_TABLE_ALIGN);
>  		dma_free_coherent(dev, size, virt, addr);
> 


-- 
~Randy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ