Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752051AbdIUPkG (ORCPT ); Thu, 21 Sep 2017 11:40:06 -0400 Received: from mail-it0-f42.google.com ([209.85.214.42]:47665 "EHLO mail-it0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751726AbdIUPkC (ORCPT ); Thu, 21 Sep 2017 11:40:02 -0400 X-Google-Smtp-Source: AOwi7QC2hkr3DQIuHJt9t8Guwdv11nj+UnSTHcc0nYN57rJnSdK0Frte68p9sw5ffWShAbzEPPRcyj1fkILfyb1Kjog= MIME-Version: 1.0 In-Reply-To: References: <1505940337-79069-1-git-send-email-keescook@chromium.org> <1505940337-79069-4-git-send-email-keescook@chromium.org> From: Kees Cook Date: Thu, 21 Sep 2017 08:40:00 -0700 X-Google-Sender-Auth: QOJ_73wATIptRE_Wn4N4fMaYDKE Message-ID: Subject: Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches To: Christopher Lameter 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" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1491 Lines: 39 On Thu, Sep 21, 2017 at 8:27 AM, Christopher Lameter wrote: > On Wed, 20 Sep 2017, Kees Cook wrote: > >> --- a/mm/slab.c >> +++ b/mm/slab.c >> @@ -1291,7 +1291,8 @@ void __init kmem_cache_init(void) >> */ >> kmalloc_caches[INDEX_NODE] = create_kmalloc_cache( >> kmalloc_info[INDEX_NODE].name, >> - kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS); >> + kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS, >> + 0, kmalloc_size(INDEX_NODE)); >> slab_state = PARTIAL_NODE; >> setup_kmalloc_cache_index_table(); > > Ok this presumes that at some point we will be able to restrict the number > of bytes writeable and thus set the offset and size field to different > values. Is that realistic? > > We already whitelist all kmalloc caches (see first patch). > > So what is the point of this patch? The DMA kmalloc caches are not whitelisted: >> 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. -Kees -- Kees Cook Pixel Security