linux-kernel - RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sgand prep_dma

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: <0CE8B6BE3C4AD74AB97D9D29BD24E55202872B3D@CORPEXCH1.na.ads.idt.com>
Date:	Mon, 6 Feb 2012 10:45:50 -0800
From:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
To:	Vinod Koul <vinod.koul@...el.com>
CC:	Russell King <rmk@....linux.org.uk>, <dan.j.williams@...el.com>,
	<linux-kernel@...r.kernel.org>, <akpm@...ux-foundation.org>,
	Jassi Brar <jaswinder.singh@...aro.org>,
	Kumar Gala <galak@...nel.crashing.org>,
	"Matt Porter" <mporter@...nel.crashing.org>,
	Li Yang <leoli@...escale.com>
Subject: RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sgand prep_dma_cyclic

On Mon, Feb 06, 2012 at 1:07 PM, Vinod Koul wrote:
> 
> On Mon, 2012-02-06 at 09:02 -0800, Bounine, Alexandre wrote:
> >
> > What if we introduce another dma_transaction_type like DMA_SLAVE_EXT
> > (extended?).
> > In this case all devices that adhere to the generic SLAVE interface
> > still be
> > registered as DMA_SLAVE and those that do not follow generic route
> use
> > DMA_SLAVE_EXT.
> that way it would be channel specific not transaction specific as you
> had asked for...?
> 
> Again, how does this solve problem of passing parameters while
> preventing abuse...

This gives a channel-specific treatment to the parameter. Channels registered
as DMA_SLAVE never expect an extra parameter (BUG_ON if the pointer is not NULL).
In the generic use scenario described by Russell clients are safe to request
any such channel without an additional HW knowledge (as it is now).

Channels registered as DMA_SLAVE_EXT will accept a pointer to parameter structure.
This, combined with configuration specific wrappers as you described
in earlier e-mail with #ifdef CONFIG_RAPIDIO, should ensure that there is no
unexpected treatment of (void *) parameter. Also for channels registered
as DMA_SLAVE_EXT a corresponding filter routine must be provided. 

Alex.