linux-kernel - Re: [PATCH 1/4] dmaengine: dw: Add peripheral bus width verification

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: <ut5notgwnjdj7ex3jeo7jnbdc2vhopebdg3miepto2wfrxti4b@b2xksvotrgph>
Date: Wed, 17 Apr 2024 22:54:42 +0300
From: Serge Semin <fancer.lancer@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Viresh Kumar <vireshk@...nel.org>, Vinod Koul <vkoul@...nel.org>, 
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	Jiri Slaby <jirislaby@...nel.org>, dmaengine@...r.kernel.org, linux-serial@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] dmaengine: dw: Add peripheral bus width verification

On Tue, Apr 16, 2024 at 09:00:50PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 16, 2024 at 07:28:55PM +0300, Serge Semin wrote:
> > Currently the src_addr_width and dst_addr_width fields of the
> > dma_slave_config structure are mapped to the CTLx.SRC_TR_WIDTH and
> > CTLx.DST_TR_WIDTH fields of the peripheral bus side in order to have the
> > properly aligned data passed to the target device. It's done just by
> > converting the passed peripheral bus width to the encoded value using the
> > __ffs() function. This implementation has several problematic sides:
> > 
> > 1. __ffs() is undefined if no bit exist in the passed value. Thus if the
> > specified addr-width is DMA_SLAVE_BUSWIDTH_UNDEFINED, __ffs() may return
> > unexpected value depending on the platform-specific implementation.
> > 
> > 2. DW AHB DMA-engine permits having the power-of-2 transfer width limited
> > by the DMAH_Mk_HDATA_WIDTH IP-core synthesize parameter. Specifying
> > bus-width out of that constraints scope will definitely cause unexpected
> > result since the destination reg will be only partly touched than the
> > client driver implied.
> > 
> > Let's fix all of that by adding the peripheral bus width verification
> > method which would make sure that the passed source or destination address
> > width is valid and if undefined then the driver will just fallback to the
> > 1-byte width transfer.
> 

> Please, add a word that you apply the check in the dwc_config() which is
> supposed to be called before preparing any transfer?

Ok.

> 
> ...
> 
> > +static int dwc_verify_p_buswidth(struct dma_chan *chan)
> > +{
> > +	struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
> > +	struct dw_dma *dw = to_dw_dma(chan->device);
> > +	u32 reg_width, max_width;
> > +
> > +	if (dwc->dma_sconfig.direction == DMA_MEM_TO_DEV)
> > +		reg_width = dwc->dma_sconfig.dst_addr_width;
> > +	else if (dwc->dma_sconfig.direction == DMA_DEV_TO_MEM)
> > +		reg_width = dwc->dma_sconfig.src_addr_width;
> 
> > +	else /* DMA_MEM_TO_MEM */
> 

> Actually not only this direction,

DW DMAC driver supports only three directions:
	dw->dma.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV) |
			     BIT(DMA_MEM_TO_MEM);
so in this case the else-clause is intended to be taken for the
DMA_MEM_TO_MEM transfers only.

> but TBH I do not see value in these comments.

Value is in signifying that DMA_MEM_TO_MEM is implied by the else
clause. If in some future point we have DMA_DEV_TO_DEV support added
to the driver, then the if-else statement must be aligned
respectively.

> 
> > +		return 0;
> > +
> > +	max_width = dw->pdata->data_width[dwc->dws.p_master];
> > +
> > +	/* Fall-back to 1byte transfer width if undefined */
> 

> 1-byte
> (as you even used in the commit message correctly)

Ok.

> 
> > +	if (reg_width == DMA_SLAVE_BUSWIDTH_UNDEFINED)
> > +		reg_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
> > +	else if (!is_power_of_2(reg_width) || reg_width > max_width)
> > +		return -EINVAL;
> > +	else /* bus width is valid */
> > +		return 0;
> > +
> > +	/* Update undefined addr width value */
> > +	if (dwc->dma_sconfig.direction == DMA_MEM_TO_DEV)
> > +		dwc->dma_sconfig.dst_addr_width = reg_width;
> > +	else /* DMA_DEV_TO_MEM */
> > +		dwc->dma_sconfig.src_addr_width = reg_width;
> 

> So, can't you simply call clamp() for both fields in dwc_config()?

Alas I can't. Because the addr-width is the non-memory peripheral
setting. We can't change it since the client drivers calculate it on
the application-specific basis (CSR widths, transfer length, etc). So
we must make sure that the specified value is supported.

> 
> > +	return 0;
> > +}
> 
> ...
> 
> > +	int err;
> 

> Hmm... we have two functions one of which is using different name for this.

Right, the driver uses both variants (see of.c, platform.c, pci.c too).

> Can we have a patch to convert to err the other one?

To be honest I'd prefer to use the "ret" name instead. It better
describes the variable usage context (Although the statements like "if
(err) ..." look a bit more readable). So I'd rather convert the "err"
vars to "ret". What do you think?

-Serge(y)

> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
>