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: <202002010952.ACDA7A81@keescook>
Date:   Sat, 1 Feb 2020 09:56:41 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Jann Horn <jannh@...gle.com>
Cc:     Christian Borntraeger <borntraeger@...ibm.com>,
        Christoph Hellwig <hch@...radead.org>,
        Christopher Lameter <cl@...ux.com>,
        Jiri Slaby <jslaby@...e.cz>,
        Julian Wiedmann <jwi@...ux.ibm.com>,
        Ursula Braun <ubraun@...ux.ibm.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        kernel list <linux-kernel@...r.kernel.org>,
        David Windsor <dave@...lcore.net>,
        Pekka Enberg <penberg@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux-MM <linux-mm@...ck.org>, linux-xfs@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andy Lutomirski <luto@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Laura Abbott <labbott@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Christoffer Dall <christoffer.dall@...aro.org>,
        Dave Kleikamp <dave.kleikamp@...cle.com>,
        Jan Kara <jack@...e.cz>,
        Luis de Bethencourt <luisbg@...nel.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Rik van Riel <riel@...hat.com>,
        Matthew Garrett <mjg59@...gle.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Michal Kubecek <mkubecek@...e.cz>
Subject: Re: [kernel-hardening] [PATCH 09/38] usercopy: Mark kmalloc caches
 as usercopy caches

On Fri, Jan 31, 2020 at 01:03:40PM +0100, Jann Horn wrote:
> I think dma-kmalloc slabs should be handled the same way as normal
> kmalloc slabs. When a dma-kmalloc allocation is freshly created, it is
> just normal kernel memory - even if it might later be used for DMA -,
> and it should be perfectly fine to copy_from_user() into such
> allocations at that point, and to copy_to_user() out of them at the
> end. If you look at the places where such allocations are created, you
> can see things like kmemdup(), memcpy() and so on - all normal
> operations that shouldn't conceptually be different from usercopy in
> any relevant way.

I can't find where the address limit for dma-kmalloc is implemented.

As to whitelisting all of dma-kmalloc -- I guess I can be talked into
it. It still seems like the memory used for direct hardware
communication shouldn't be exposed to userspace, but it we're dealing
with packet data, etc, then it makes sense not to have to have bounce
buffers, etc.

-- 
Kees Cook

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ