Thread (77 messages) 77 messages, 13 authors, 2020-04-20

Re: [kernel-hardening] [PATCH 09/38] usercopy: Mark kmalloc caches as usercopy caches

From: Kees Cook <hidden>
Date: 2020-01-28 23:02:00
Also in: linux-arch, linux-fsdevel, linux-mm, linux-xfs, lkml

On Tue, Jan 28, 2020 at 08:58:31AM +0100, Christian Borntraeger wrote:

On 28.01.20 00:19, Kees Cook wrote:
quoted
On Thu, Jan 23, 2020 at 09:14:20AM +0100, Jiri Slaby wrote:
quoted
On 14. 11. 19, 22:27, Kees Cook wrote:
quoted
On Tue, Nov 12, 2019 at 01:21:54PM -0800, Kees Cook wrote:
quoted
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/ (local)
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help