From: Kees Cook <keescook@chromium.org>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Jiri Slaby <jslaby@suse.cz>, Julian Wiedmann <jwi@linux.ibm.com>,
Ursula Braun <ubraun@linux.ibm.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
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@kvack.org, linux-xfs@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Christoph Lameter <cl@linux.com>,
"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@vger.kernel.org, linux-arch@vger.kernel.org,
netdev@vger.kernel.org, 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: Tue, 28 Jan 2020 15:01:53 -0800 [thread overview]
Message-ID: <202001281457.FA11CC313A@keescook> (raw)
In-Reply-To: <5861936c-1fe1-4c44-d012-26efa0c8b6e7@de.ibm.com>
On Tue, Jan 28, 2020 at 08:58:31AM +0100, Christian Borntraeger wrote:
>
>
> On 28.01.20 00:19, Kees Cook wrote:
> > On Thu, Jan 23, 2020 at 09:14:20AM +0100, Jiri Slaby wrote:
> >> On 14. 11. 19, 22:27, Kees Cook wrote:
> >>> On Tue, Nov 12, 2019 at 01:21:54PM -0800, Kees Cook wrote:
> >>>> How is iucv the only network protocol that has run into this? Do others
> >>>> use a bounce buffer?
> >>>
> >>> Another solution would be to use a dedicated kmem cache (instead of the
> >>> shared kmalloc dma one)?
> >>
> >> Has there been any conclusion to this thread yet? For the time being, we
> >> disabled HARDENED_USERCOPY on s390...
> >>
> >> https://lore.kernel.org/kernel-hardening/9519edb7-456a-a2fa-659e-3e5a1ff89466@suse.cz/
> >
> > I haven't heard anything new. What did people think of a separate kmem
> > cache?
> >
>
> Adding Julian and Ursula. A separate kmem cache for iucv might be indeed
> a solution for the user hardening issue.
It should be very clean -- any existing kmallocs already have to be
"special" in the sense that they're marked with the DMA flag. So
converting these to a separate cache should be mostly mechanical.
> On the other hand not marking the DMA caches still seems questionable.
My understanding is that exposing DMA memory to userspace copies can
lead to unexpected results, especially for misbehaving hardware, so I'm
not convinced this is a generically bad hardening choice.
-Kees
>
> For reference
> https://bugzilla.suse.com/show_bug.cgi?id=1156053
> the kernel hardening now triggers a warning.
>
--
Kees Cook
next prev parent reply other threads:[~2020-01-28 23:02 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 [this message]
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
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=202001281457.FA11CC313A@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=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).