linux-kernel - Re: [PATCH 2/4] scatterlist: add sg_alloc_table_from

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:	Thu, 31 Mar 2016 16:45:57 +0200
From:	Boris Brezillon <boris.brezillon@...e-electrons.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	linux-mtd@...ts.infradead.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dave Gordon <david.s.gordon@...el.com>,
	linux-crypto@...r.kernel.org,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Vinod Koul <vinod.koul@...el.com>,
	Richard Weinberger <richard@....at>,
	Joerg Roedel <joro@...tes.org>, linux-kernel@...r.kernel.org,
	linux-spi@...r.kernel.org, Vignesh R <vigneshr@...com>,
	linux-mm@...ck.org, iommu@...ts.linux-foundation.org,
	Mark Brown <broonie@...nel.org>,
	Hans Verkuil <hans.verkuil@...co.com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	dmaengine@...r.kernel.org, Dan Williams <dan.j.williams@...el.com>,
	linux-media@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	linux-arm-kernel@...ts.infradead.org,
	Mauro Carvalho Chehab <m.chehab@...sung.com>
Subject: Re: [PATCH 2/4] scatterlist: add sg_alloc_table_from_buf() helper

Hi Russell,

On Thu, 31 Mar 2016 15:14:13 +0100
Russell King - ARM Linux <linux@....linux.org.uk> wrote:

> On Thu, Mar 31, 2016 at 02:29:42PM +0200, Boris Brezillon wrote:
> > sg_alloc_table_from_buf() provides an easy solution to create an sg_table
> > from a virtual address pointer. This function takes care of dealing with
> > vmallocated buffers, buffer alignment, or DMA engine limitations (maximum
> > DMA transfer size).
> 
> Please note that the DMA API does not take account of coherency of memory
> regions other than non-high/lowmem - there are specific extensions to
> deal with this.

Ok, you said 'non-high/lowmem', this means vmalloced and kmapped buffers
already fall in this case, right?

Could you tell me more about those specific extensions?

> 
> What this means is that having an API that takes any virtual address
> pointer, converts it to a scatterlist which is then DMA mapped, is
> unsafe.

Which means some implementations already get this wrong (see
spi_map_buf(), and I'm pretty sure it's not the only one).

> 
> It'll be okay for PIPT and non-aliasing VIPT cache architectures, but
> for other cache architectures this will hide this problem and make
> review harder.
> 

Ok, you lost me. I'll have to do my homework and try to understand what
this means :).

Thanks for your valuable inputs.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com