Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751839AbdIUS0s (ORCPT ); Thu, 21 Sep 2017 14:26:48 -0400 Received: from mail-io0-f177.google.com ([209.85.223.177]:55211 "EHLO mail-io0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751629AbdIUS0p (ORCPT ); Thu, 21 Sep 2017 14:26:45 -0400 X-Google-Smtp-Source: AOwi7QDYwP7eE4mDf5goXzs9ki3D4LWEv5+mHfuWw/eR9qwbSXyZldmTkauuKiD9Pxh/JSEm30WuGCgTu6+ab6ws73U= 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 11:26:43 -0700 X-Google-Sender-Auth: oUNdyF0Fco1OMzmGI2omR2BaWag 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: 1542 Lines: 42 On Thu, Sep 21, 2017 at 9:04 AM, Christopher Lameter wrote: > 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. > > ?? They may be obsolete, but they're still in the kernel, and they aren't copied to userspace, so we can mark them. >> >> 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? Patch 1 is to allow for things to mark their whitelists. Patch 30 disables the full whitelisting, since then we've defined them all, so the kmalloc caches need to mark themselves as whitelisted. Patch 1 leaves unmarked things whitelisted so we can progressively tighten the restriction and have a bisectable series. (i.e. if there is something wrong with one of the whitelists in the series, it will bisect to that one, not the one that removes the global whitelist from patch 1.) -Kees -- Kees Cook Pixel Security