Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751728AbdIUQEk (ORCPT ); Thu, 21 Sep 2017 12:04:40 -0400 Received: from resqmta-ch2-06v.sys.comcast.net ([69.252.207.38]:58476 "EHLO resqmta-ch2-06v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751602AbdIUQEi (ORCPT ); Thu, 21 Sep 2017 12:04:38 -0400 Date: Thu, 21 Sep 2017 11:04:35 -0500 (CDT) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake 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" Subject: Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches In-Reply-To: Message-ID: References: <1505940337-79069-1-git-send-email-keescook@chromium.org> <1505940337-79069-4-git-send-email-keescook@chromium.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfGui2bjrU8KCYXIHmtfE1oiB1kxDpDS64S4i2w5mlIuiynraSA/j+FuQpYRWDUaQkiqhceR5ZkH+mZN5Yup8cqvu77SGPwg6vDFh+ra4uZOy97gzKo8q zhrxPownCjJPh1ZpX8PXUgEBOY9ZYP0qwjCOmsThhzpRY2tn3Ow4RS5G0Xz8wSYkGqEqVolHEJZ7sSnjHvStlk4mROgrkh+jKYhdoMyjLJT+VC1Q2GXAX+4f qnQzbprovwtF2UnMG29ULbq5NfuudxuyAOYOU8cOehWTPNm4IJMbUkZZy7e/oXcQi1SxulQeBc5SHqY8hVF8phlLgVtG9hhiTLRh1yCIHvVSLRCD70ty2igk kDVq55f2WcISNnoPDchtNsUHgjcjUxR4n7z40hYl7t24XAJLkEW9ngG1YZaQZxrqaPPKTBDvHIh6CZZQC4I8n5H4Br5uQNpmU1nckdNhd1X6lqYlWzK0MWr3 mwPDktIQJHWEchon8mBkJ9NyMntfmoS03bXSH4WMOvNuitV/lJuEO+STkHBN6IfDkiNwF8RGFw7mDIIEyxe3hNGGEhdDjFvKgx+UuA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 806 Lines: 22 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?