From: Kees Cook <keescook@chromium.org>
To: Jann Horn <jannh@google.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
Christoph Hellwig <hch@infradead.org>,
Christopher Lameter <cl@linux.com>, Jiri Slaby <jslaby@suse.cz>,
Julian Wiedmann <jwi@linux.ibm.com>,
Ursula Braun <ubraun@linux.ibm.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
kernel list <linux-kernel@vger.kernel.org>,
David Windsor <dave@nullcore.net>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
linux-xfs@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Laura Abbott <labbott@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Christoffer Dall <christoffer.dall@linaro.org>,
Dave Kleikamp <dave.kleikamp@oracle.com>, Jan Kara <jack@suse.cz>,
Luis de Bethencourt <luisbg@kernel.org>,
Marc Zyngier <marc.zyngier@arm.com>,
Rik van Riel <riel@redhat.com>,
Matthew Garrett <mjg59@google.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
Vlastimil Babka <vbabka@suse.cz>,
Michal Kubecek <mkubecek@suse.cz>
Subject: Re: [kernel-hardening] [PATCH 09/38] usercopy: Mark kmalloc caches as usercopy caches
Date: Sat, 1 Feb 2020 09:56:41 -0800 [thread overview]
Message-ID: <202002010952.ACDA7A81@keescook> (raw)
In-Reply-To: <CAG48ez1a4waGk9kB0WLaSbs4muSoK0AYAVk8=XYaKj4_+6e6Hg@mail.gmail.com>
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
next prev parent reply other threads:[~2020-02-01 17:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1515636190-24061-1-git-send-email-keescook@chromium.org>
2018-01-11 2:02 ` [PATCH 06/38] usercopy: Prepare for usercopy whitelisting Kees Cook
2018-01-11 2:02 ` [PATCH 07/38] usercopy: WARN() on slab cache usercopy region violations Kees Cook
2018-01-11 2:02 ` [PATCH 09/38] usercopy: Mark kmalloc caches as usercopy caches Kees Cook
2019-11-12 7:17 ` [kernel-hardening] " Jiri Slaby
2019-11-12 21:21 ` Kees Cook
2019-11-14 21:27 ` Kees Cook
2020-01-23 8:14 ` Jiri Slaby
2020-01-27 23:19 ` Kees Cook
2020-01-28 7:58 ` Christian Borntraeger
2020-01-28 23:01 ` Kees Cook
2020-01-29 9:26 ` Ursula Braun
2020-01-29 16:43 ` Christopher Lameter
2020-01-29 17:07 ` Christian Borntraeger
2020-01-29 17:09 ` Christoph Hellwig
2020-01-29 17:19 ` Christian Borntraeger
2020-01-30 19:23 ` Kees Cook
2020-01-31 12:03 ` Jann Horn
2020-02-01 17:56 ` Kees Cook [this message]
2020-02-01 19:27 ` Jann Horn
2020-02-03 7:46 ` Matthew Wilcox
2020-02-03 17:41 ` Christoph Hellwig
2020-02-03 17:20 ` Christopher Lameter
2020-04-07 8:00 ` Vlastimil Babka
2020-04-07 11:05 ` Christian Borntraeger
2020-04-20 7:53 ` Jiri Slaby
2020-04-20 17:43 ` Kees Cook
2020-02-03 17:38 ` Christoph Hellwig
2020-02-03 17:36 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202002010952.ACDA7A81@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@de.ibm.com \
--cc=christoffer.dall@linaro.org \
--cc=cl@linux.com \
--cc=dave.kleikamp@oracle.com \
--cc=dave@nullcore.net \
--cc=davem@davemloft.net \
--cc=hch@infradead.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=jslaby@suse.cz \
--cc=jwi@linux.ibm.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=luisbg@kernel.org \
--cc=luto@kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=martin.petersen@oracle.com \
--cc=mjg59@google.com \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=penberg@kernel.org \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=torvalds@linux-foundation.org \
--cc=ubraun@linux.ibm.com \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).