linux-kernel - Re: [PATCH] Introduce dmam_zalloc

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] [day] [month] [year] [list]

Message-id: <6a551a81-748f-e069-8ffd-20ef13e34453@samsung.com>
Date:   Thu, 10 Aug 2017 08:58:54 +0200
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Christoph Hellwig <hch@....de>,
        Michael Moese <michael.moese@....de>
Cc:     Robin Murphy <robin.murphy@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Introduce dmam_zalloc_coherent()

Hi Christoph,

On 2017-08-09 15:37, Christoph Hellwig wrote:
> On Tue, Aug 08, 2017 at 11:15:35AM +0200, Michael Moese wrote:
>> All memory allocation functions have a pendant for allocating zeroed
>> memory, but dmam_alloc_coherent does not have such a pendant.
>> However, it is easier to read dmam_zalloc_coherent than passing an extra
>> flag or, even worse, see memset() after the allocation.
>> This patch adds an inline function dmam_zalloc_coherent(), exactly like
>> the implementation of dma_zalloc_coherent().
> I'm a bit worried about the __GFP_ZERO as we have lots of non-kmalloc
> implementations of these.  But on the other hand we already implement
> dma_zalloc_coherent the same way, which means we'd already buggy.
>
> So I plan to apply this for 4.14, but I also plan to spend some time
> to implement all the existin alloc ops to make sure it's going to work
> fine.

Frankly, since introducing dma_mmap_coherent, dma_alloc_coherent already
clears allocated buffers to avoid potential information leak to userspace.
There are even drivers that rely on such behavior, see
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-April/338804.html

Maybe it would make sense to properly document it and then convert
dma_zalloc* to standard dma_alloc_* calls?

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland