linux-kernel - Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc

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: <CAMuHMdWOr0EsgFQF8tjJYLxKVXx+Jwn73N8SVKt8AQGLKQ8V-A@mail.gmail.com>
Date:   Fri, 14 Dec 2018 10:54:32 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Christoph Hellwig <hch@....de>
Cc:     Linux IOMMU <iommu@...ts.linux-foundation.org>,
        Michal Simek <monstr@...str.eu>, ashutosh.dixit@...el.com,
        alpha <linux-alpha@...r.kernel.org>,
        arcml <linux-snps-arc@...ts.infradead.org>,
        linux-c6x-dev@...ux-c6x.org,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Openrisc <openrisc@...ts.librecores.org>,
        Parisc List <linux-parisc@...r.kernel.org>,
        linux-s390 <linux-s390@...r.kernel.org>,
        sparclinux <sparclinux@...r.kernel.org>,
        linux-xtensa@...ux-xtensa.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*

Hi Christoph,

On Fri, Dec 14, 2018 at 9:26 AM Christoph Hellwig <hch@....de> wrote:
> If we want to map memory from the DMA allocator to userspace it must be
> zeroed at allocation time to prevent stale data leaks.   We already do
> this on most common architectures, but some architectures don't do this
> yet, fix them up, either by passing GFP_ZERO when we use the normal page
> allocator or doing a manual memset otherwise.
>
> Signed-off-by: Christoph Hellwig <hch@....de>

Thanks for your patch!

> --- a/arch/m68k/kernel/dma.c
> +++ b/arch/m68k/kernel/dma.c
> @@ -32,7 +32,7 @@ void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
>         size = PAGE_ALIGN(size);
>         order = get_order(size);
>
> -       page = alloc_pages(flag, order);
> +       page = alloc_pages(flag | GFP_ZERO, order);
>         if (!page)
>                 return NULL;

There's second implementation below, which calls __get_free_pages() and
does an explicit memset().  As __get_free_pages() calls alloc_pages(), perhaps
it makes sense to replace the memset() by GFP_ZERO, to increase consistency?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds