From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Lameter Subject: Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches Date: Thu, 21 Sep 2017 11:04:35 -0500 (CDT) Message-ID: References: <1505940337-79069-1-git-send-email-keescook@chromium.org> <1505940337-79069-4-git-send-email-keescook@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Kees Cook Cc: LKML , David Windsor , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Linux-MM , linux-xfs@vger.kernel.org, "linux-fsdevel@vger.kernel.org" , Network Development , "kernel-hardening@lists.openwall.com" List-Id: linux-mm.kvack.org On Thu, 21 Sep 2017, Kees Cook wrote: > > So what is the point of this patch? > > The DMA kmalloc caches are not whitelisted: The DMA kmalloc caches are pretty obsolete and mostly there for obscure drivers. ?? > >> kmalloc_dma_caches[i] = create_kmalloc_cache(n, > >> - size, SLAB_CACHE_DMA | flags); > >> + size, SLAB_CACHE_DMA | flags, 0, 0); > > So this is creating the distinction between the kmallocs that go to > userspace and those that don't. The expectation is that future work > can start to distinguish between "for userspace" and "only kernel" > kmalloc allocations, as is already done here for DMA. The creation of the kmalloc caches in earlier patches already setup the "whitelisting". Why do it twice?