[{"id":1772933,"web_url":"http://patchwork.ozlabs.org/comment/1772933/","msgid":"<alpine.DEB.2.20.1709211024120.14427@nuc-kabylake>","list_archive_url":null,"date":"2017-09-21T15:27:13","subject":"Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy\n\tcaches","submitter":{"id":2224,"url":"http://patchwork.ozlabs.org/api/people/2224/","name":"Christoph Lameter (Ampere)","email":"cl@linux.com"},"content":"On Wed, 20 Sep 2017, Kees Cook wrote:\n\n> --- a/mm/slab.c\n> +++ b/mm/slab.c\n> @@ -1291,7 +1291,8 @@ void __init kmem_cache_init(void)\n>  \t */\n>  \tkmalloc_caches[INDEX_NODE] = create_kmalloc_cache(\n>  \t\t\t\tkmalloc_info[INDEX_NODE].name,\n> -\t\t\t\tkmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS);\n> +\t\t\t\tkmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS,\n> +\t\t\t\t0, kmalloc_size(INDEX_NODE));\n>  \tslab_state = PARTIAL_NODE;\n>  \tsetup_kmalloc_cache_index_table();\n\nOk this presumes that at some point we will be able to restrict the number\nof bytes writeable and thus set the offset and size field to different\nvalues. Is that realistic?\n\nWe already whitelist all kmalloc caches (see first patch).\n\nSo what is the point of this patch?","headers":{"Return-Path":"<netdev-owner@vger.kernel.org>","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xygfm4R6kz9t4B\n\tfor <patchwork-incoming@ozlabs.org>;\n\tFri, 22 Sep 2017 01:35:28 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751787AbdIUPf0 (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tThu, 21 Sep 2017 11:35:26 -0400","from resqmta-ch2-05v.sys.comcast.net ([69.252.207.37]:50962 \"EHLO\n\tresqmta-ch2-05v.sys.comcast.net\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751723AbdIUPfY (ORCPT\n\t<rfc822;netdev@vger.kernel.org>); Thu, 21 Sep 2017 11:35:24 -0400","from resomta-ch2-05v.sys.comcast.net ([69.252.207.101])\n\tby resqmta-ch2-05v.sys.comcast.net with ESMTP\n\tid v3NcdleiutpbPv3NjdIkfS; Thu, 21 Sep 2017 15:27:15 +0000","from gentwo.org ([98.222.162.64])\n\tby resomta-ch2-05v.sys.comcast.net with SMTP\n\tid v3NhdKepCjdGuv3Nid8Ms7; Thu, 21 Sep 2017 15:27:15 +0000","by gentwo.org (Postfix, from userid 1001)\n\tid CA1E511627C8; Thu, 21 Sep 2017 10:27:13 -0500 (CDT)","from localhost (localhost [127.0.0.1])\n\tby gentwo.org (Postfix) with ESMTP id C6BAB11602E4;\n\tThu, 21 Sep 2017 10:27:13 -0500 (CDT)"],"Date":"Thu, 21 Sep 2017 10:27:13 -0500 (CDT)","From":"Christopher Lameter <cl@linux.com>","X-X-Sender":"cl@nuc-kabylake","To":"Kees Cook <keescook@chromium.org>","cc":"linux-kernel@vger.kernel.org, David Windsor <dave@nullcore.net>,\n\tPekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>,\n\tJoonsoo Kim <iamjoonsoo.kim@lge.com>,\n\tAndrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,\n\tlinux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,\n\tnetdev@vger.kernel.org, kernel-hardening@lists.openwall.com","Subject":"Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy\n\tcaches","In-Reply-To":"<1505940337-79069-4-git-send-email-keescook@chromium.org>","Message-ID":"<alpine.DEB.2.20.1709211024120.14427@nuc-kabylake>","References":"<1505940337-79069-1-git-send-email-keescook@chromium.org>\n\t<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":"MS4wfOOCKBKLtTEqV29KUFThZxG2ymxFPth/5UYhqvx8DNAPcmw207xZNPFj9ieIZGeQIp8qtfoSZL03sFMa6rpv2iyduSj6PlfTRluj2qrW0bEzKPa2Mdzc\n\tmV+XP1F4nxZiKf6ST28dmYUGZwatNeqMTjIFJafd91AkKSYs361zZUN6HhZhuajBFLFQma2kwUbKspPZV6HJ6/gutG48VVC1P3+njc+M1rniwNLvWXLGskt9\n\tMGFQ+fvsoMg4fEk4sfXv9IeMuZbytEap0RVbnfKYBh8CT+tNoAsP4IWq2f+vCXExZDchbiPCw3OP0I2jeVX/GxtMlwVALUyCBQ3vpINkT/GAv1cUw9EPhyIo\n\tAjRxjHSHqUdiWelotvdWiA2ygZbZPVXqnTcAZp10qGN65wWDiOYuUjwgJK5KQ/HATJDB0i+Nxu/k6Bpxn517oN2msNiIv34dPcKQ8TMAsr7bEvcz+VZLgRU7\n\tgJB+kxUT4B/vFPeaOL8+4Z6604v5wtMJfXnu224nkQHZtM6ObjOwmEWCkcwEwDUljbp9Fo1I0DvvbQ27vHzVHOdtgg0raBPjH912sg==","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<netdev.vger.kernel.org>","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1772942,"web_url":"http://patchwork.ozlabs.org/comment/1772942/","msgid":"<CAGXu5j+X6dWCGocG=P7pszTY-5OZ6Jmp-RsnDKox75M5rmVe4g@mail.gmail.com>","list_archive_url":null,"date":"2017-09-21T15:40:00","subject":"Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc\n\tcaches as usercopy caches","submitter":{"id":10641,"url":"http://patchwork.ozlabs.org/api/people/10641/","name":"Kees Cook","email":"keescook@chromium.org"},"content":"On Thu, Sep 21, 2017 at 8:27 AM, Christopher Lameter <cl@linux.com> wrote:\n> On Wed, 20 Sep 2017, Kees Cook wrote:\n>\n>> --- a/mm/slab.c\n>> +++ b/mm/slab.c\n>> @@ -1291,7 +1291,8 @@ void __init kmem_cache_init(void)\n>>        */\n>>       kmalloc_caches[INDEX_NODE] = create_kmalloc_cache(\n>>                               kmalloc_info[INDEX_NODE].name,\n>> -                             kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS);\n>> +                             kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS,\n>> +                             0, kmalloc_size(INDEX_NODE));\n>>       slab_state = PARTIAL_NODE;\n>>       setup_kmalloc_cache_index_table();\n>\n> Ok this presumes that at some point we will be able to restrict the number\n> of bytes writeable and thus set the offset and size field to different\n> values. Is that realistic?\n>\n> We already whitelist all kmalloc caches (see first patch).\n>\n> So what is the point of this patch?\n\nThe DMA kmalloc caches are not whitelisted:\n\n>>                         kmalloc_dma_caches[i] = create_kmalloc_cache(n,\n>> -                               size, SLAB_CACHE_DMA | flags);\n>> +                               size, SLAB_CACHE_DMA | flags, 0, 0);\n\nSo this is creating the distinction between the kmallocs that go to\nuserspace and those that don't. The expectation is that future work\ncan start to distinguish between \"for userspace\" and \"only kernel\"\nkmalloc allocations, as is already done here for DMA.\n\n-Kees","headers":{"Return-Path":"<netdev-owner@vger.kernel.org>","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=google.com header.i=@google.com\n\theader.b=\"P6TPh7iP\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=chromium.org header.i=@chromium.org\n\theader.b=\"KGWAzI/+\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xygmM1hdxz9s7c\n\tfor <patchwork-incoming@ozlabs.org>;\n\tFri, 22 Sep 2017 01:40:19 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751922AbdIUPkG (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tThu, 21 Sep 2017 11:40:06 -0400","from mail-it0-f54.google.com ([209.85.214.54]:50799 \"EHLO\n\tmail-it0-f54.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751879AbdIUPkC (ORCPT\n\t<rfc822;netdev@vger.kernel.org>); Thu, 21 Sep 2017 11:40:02 -0400","by mail-it0-f54.google.com with SMTP id y138so1016632itc.5\n\tfor <netdev@vger.kernel.org>; Thu, 21 Sep 2017 08:40:02 -0700 (PDT)","by 10.107.178.131 with HTTP; Thu, 21 Sep 2017 08:40:00 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=google.com; s=20161025;\n\th=mime-version:sender:in-reply-to:references:from:date:message-id\n\t:subject:to:cc;\n\tbh=pFZIYyHpqh6tGAL+SEoj2GZca7obHBG2nIrktcxJKE0=;\n\tb=P6TPh7iPeFTj7aFyr/v+/V1xUPGKgXpvZLvkHFc8MiQdli4nP+ZCDK0WyLPXajkMIY\n\tApHA8Q8n2uQNuyDOXYil4xGaTPExqPJWqa3wm57QtmXa3dPncS+S8pCytbdJvfj7Pc62\n\tYCCs7M2tHuWRUbKPt+Ir0q9usP/L5VmTeL4Gq2/zM6nEA2whqOep8PxwSVsFpUQQzOaj\n\tQz6r4CAik9BPJa7N1o3JH4DFAuGclqM8dO3OZpVNlzWLYGpHGZpaZQfmOPJ7yKJBsrYx\n\thUOVV1pT/2jCcjc84QjfqKiGHKFotkJY0pKvf1VkWw679jUzCoI4idGqe6n58o3Avm5M\n\tzAUg==","v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=chromium.org; s=google;\n\th=mime-version:sender:in-reply-to:references:from:date:message-id\n\t:subject:to:cc;\n\tbh=pFZIYyHpqh6tGAL+SEoj2GZca7obHBG2nIrktcxJKE0=;\n\tb=KGWAzI/+dSBynQ2RY9G4oNY17qs4Aqu8RMC7h8d7uEredkMVJH0bR+jlUK57ruJruo\n\twQCeYy3NCh5ITw8+ZpcHMoklYLjk0B+yJOvpkYWpKK5AipY8uswUvaKxTnz+ihq5tEe1\n\tMcEejukazdfsjSv1DOh0LUdXTM/Sz+INzA7vk="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:sender:in-reply-to:references:from\n\t:date:message-id:subject:to:cc;\n\tbh=pFZIYyHpqh6tGAL+SEoj2GZca7obHBG2nIrktcxJKE0=;\n\tb=E4GQdZR4iueBcewZcVlUjE+MfkoSQ04gYy7NQF7I5d17Oy1ZfwRW7cpMVoid57jtYN\n\th/69dcbAUmr/0M5vCQomdOr7BMpx0U0xdnwgoyjc9mwMGlb683R+Ri3a9p9LyPUOCV8K\n\tgAPjQd1VnXtTJ3XUdTS8+D16QMXkMGw22BxpIp4BfevIaLG6mcYzi8aKDOZspsQg5N8P\n\tLHhNaQcsm2Tl6G0yWqZnQHiixP6Jq2rekFr3fmOyhX8qWNy/ow07tUvbTJzAaxpu7wRF\n\tU4nsqqvWijniEdnn3iyTSySu1089PbmBF6XTS0GtRzd8nvo6mmQatBswLZD3EKk9+pUe\n\t7u2Q==","X-Gm-Message-State":"AHPjjUikDCejLKZyKgKpmjzVkW7ZV1F++X4P6X5A3uvvVdM9dc7uVtWD\n\tbyJVoMwd62cpeJqB4JyThNwZYFrNelnDtXAIYKHlHA==","X-Google-Smtp-Source":"AOwi7QC2hkr3DQIuHJt9t8Guwdv11nj+UnSTHcc0nYN57rJnSdK0Frte68p9sw5ffWShAbzEPPRcyj1fkILfyb1Kjog=","X-Received":"by 10.36.121.202 with SMTP id z193mr2039406itc.110.1506008401856;\n\tThu, 21 Sep 2017 08:40:01 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<alpine.DEB.2.20.1709211024120.14427@nuc-kabylake>","References":"<1505940337-79069-1-git-send-email-keescook@chromium.org>\n\t<1505940337-79069-4-git-send-email-keescook@chromium.org>\n\t<alpine.DEB.2.20.1709211024120.14427@nuc-kabylake>","From":"Kees Cook <keescook@chromium.org>","Date":"Thu, 21 Sep 2017 08:40:00 -0700","X-Google-Sender-Auth":"QOJ_73wATIptRE_Wn4N4fMaYDKE","Message-ID":"<CAGXu5j+X6dWCGocG=P7pszTY-5OZ6Jmp-RsnDKox75M5rmVe4g@mail.gmail.com>","Subject":"Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc\n\tcaches as usercopy caches","To":"Christopher Lameter <cl@linux.com>","Cc":"LKML <linux-kernel@vger.kernel.org>, David Windsor <dave@nullcore.net>,\n\tPekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>,\n\tJoonsoo Kim <iamjoonsoo.kim@lge.com>,\n\tAndrew Morton <akpm@linux-foundation.org>,\n\tLinux-MM <linux-mm@kvack.org>, linux-xfs@vger.kernel.org,\n\t\"linux-fsdevel@vger.kernel.org\" <linux-fsdevel@vger.kernel.org>,\n\tNetwork Development <netdev@vger.kernel.org>,\n\t\"kernel-hardening@lists.openwall.com\" \n\t<kernel-hardening@lists.openwall.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<netdev.vger.kernel.org>","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1772955,"web_url":"http://patchwork.ozlabs.org/comment/1772955/","msgid":"<alpine.DEB.2.20.1709211102320.14742@nuc-kabylake>","list_archive_url":null,"date":"2017-09-21T16:04:35","subject":"Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc\n\tcaches as usercopy caches","submitter":{"id":2224,"url":"http://patchwork.ozlabs.org/api/people/2224/","name":"Christoph Lameter (Ampere)","email":"cl@linux.com"},"content":"On Thu, 21 Sep 2017, Kees Cook wrote:\n\n> > So what is the point of this patch?\n>\n> The DMA kmalloc caches are not whitelisted:\n\nThe DMA kmalloc caches are pretty obsolete and mostly there for obscure\ndrivers.\n\n??\n\n> >>                         kmalloc_dma_caches[i] = create_kmalloc_cache(n,\n> >> -                               size, SLAB_CACHE_DMA | flags);\n> >> +                               size, SLAB_CACHE_DMA | flags, 0, 0);\n>\n> So this is creating the distinction between the kmallocs that go to\n> userspace and those that don't. The expectation is that future work\n> can start to distinguish between \"for userspace\" and \"only kernel\"\n> kmalloc allocations, as is already done here for DMA.\n\nThe creation of the kmalloc caches in earlier patches already setup the\n\"whitelisting\". Why do it twice?","headers":{"Return-Path":"<netdev-owner@vger.kernel.org>","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xyhJf5PZjz9t42\n\tfor <patchwork-incoming@ozlabs.org>;\n\tFri, 22 Sep 2017 02:04:50 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751700AbdIUQEj (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tThu, 21 Sep 2017 12:04:39 -0400","from resqmta-ch2-06v.sys.comcast.net ([69.252.207.38]:58474 \"EHLO\n\tresqmta-ch2-06v.sys.comcast.net\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751596AbdIUQEi (ORCPT\n\t<rfc822;netdev@vger.kernel.org>); Thu, 21 Sep 2017 12:04:38 -0400","from resomta-ch2-08v.sys.comcast.net ([69.252.207.104])\n\tby resqmta-ch2-06v.sys.comcast.net with ESMTP\n\tid v3xtdd2TpbRLmv3xtdiVGR; Thu, 21 Sep 2017 16:04:37 +0000","from gentwo.org ([98.222.162.64])\n\tby resomta-ch2-08v.sys.comcast.net with SMTP\n\tid v3xsd1wT9XNPSv3xsdTO3T; Thu, 21 Sep 2017 16:04:37 +0000","by gentwo.org (Postfix, from userid 1001)\n\tid EFABF11627D2; Thu, 21 Sep 2017 11:04:35 -0500 (CDT)","from localhost (localhost [127.0.0.1])\n\tby gentwo.org (Postfix) with ESMTP id EC78C11627D1;\n\tThu, 21 Sep 2017 11:04:35 -0500 (CDT)"],"Date":"Thu, 21 Sep 2017 11:04:35 -0500 (CDT)","From":"Christopher Lameter <cl@linux.com>","X-X-Sender":"cl@nuc-kabylake","To":"Kees Cook <keescook@chromium.org>","cc":"LKML <linux-kernel@vger.kernel.org>, David Windsor <dave@nullcore.net>,\n\tPekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>,\n\tJoonsoo Kim <iamjoonsoo.kim@lge.com>,\n\tAndrew Morton <akpm@linux-foundation.org>,\n\tLinux-MM <linux-mm@kvack.org>, linux-xfs@vger.kernel.org,\n\t\"linux-fsdevel@vger.kernel.org\" <linux-fsdevel@vger.kernel.org>,\n\tNetwork Development <netdev@vger.kernel.org>,\n\t\"kernel-hardening@lists.openwall.com\" \n\t<kernel-hardening@lists.openwall.com>","Subject":"Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc\n\tcaches as usercopy caches","In-Reply-To":"<CAGXu5j+X6dWCGocG=P7pszTY-5OZ6Jmp-RsnDKox75M5rmVe4g@mail.gmail.com>","Message-ID":"<alpine.DEB.2.20.1709211102320.14742@nuc-kabylake>","References":"<1505940337-79069-1-git-send-email-keescook@chromium.org>\n\t<1505940337-79069-4-git-send-email-keescook@chromium.org>\n\t<alpine.DEB.2.20.1709211024120.14427@nuc-kabylake>\n\t<CAGXu5j+X6dWCGocG=P7pszTY-5OZ6Jmp-RsnDKox75M5rmVe4g@mail.gmail.com>","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\n\tzhrxPownCjJPh1ZpX8PXUgEBOY9ZYP0qwjCOmsThhzpRY2tn3Ow4RS5G0Xz8wSYkGqEqVolHEJZ7sSnjHvStlk4mROgrkh+jKYhdoMyjLJT+VC1Q2GXAX+4f\n\tqnQzbprovwtF2UnMG29ULbq5NfuudxuyAOYOU8cOehWTPNm4IJMbUkZZy7e/oXcQi1SxulQeBc5SHqY8hVF8phlLgVtG9hhiTLRh1yCIHvVSLRCD70ty2igk\n\tkDVq55f2WcISNnoPDchtNsUHgjcjUxR4n7z40hYl7t24XAJLkEW9ngG1YZaQZxrqaPPKTBDvHIh6CZZQC4I8n5H4Br5uQNpmU1nckdNhd1X6lqYlWzK0MWr3\n\tmwPDktIQJHWEchon8mBkJ9NyMntfmoS03bXSH4WMOvNuitV/lJuEO+STkHBN6IfDkiNwF8RGFw7mDIIEyxe3hNGGEhdDjFvKgx+UuA==","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<netdev.vger.kernel.org>","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1773049,"web_url":"http://patchwork.ozlabs.org/comment/1773049/","msgid":"<CAGXu5jKqWShVMqm6-moqgO7JUaJuFxw-9mMKak+WG1HgNJqc1Q@mail.gmail.com>","list_archive_url":null,"date":"2017-09-21T18:26:43","subject":"Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc\n\tcaches as usercopy caches","submitter":{"id":10641,"url":"http://patchwork.ozlabs.org/api/people/10641/","name":"Kees Cook","email":"keescook@chromium.org"},"content":"On Thu, Sep 21, 2017 at 9:04 AM, Christopher Lameter <cl@linux.com> wrote:\n> On Thu, 21 Sep 2017, Kees Cook wrote:\n>\n>> > So what is the point of this patch?\n>>\n>> The DMA kmalloc caches are not whitelisted:\n>\n> The DMA kmalloc caches are pretty obsolete and mostly there for obscure\n> drivers.\n>\n> ??\n\nThey may be obsolete, but they're still in the kernel, and they aren't\ncopied to userspace, so we can mark them.\n\n>> >>                         kmalloc_dma_caches[i] = create_kmalloc_cache(n,\n>> >> -                               size, SLAB_CACHE_DMA | flags);\n>> >> +                               size, SLAB_CACHE_DMA | flags, 0, 0);\n>>\n>> So this is creating the distinction between the kmallocs that go to\n>> userspace and those that don't. The expectation is that future work\n>> can start to distinguish between \"for userspace\" and \"only kernel\"\n>> kmalloc allocations, as is already done here for DMA.\n>\n> The creation of the kmalloc caches in earlier patches already setup the\n> \"whitelisting\". Why do it twice?\n\nPatch 1 is to allow for things to mark their whitelists. Patch 30\ndisables the full whitelisting, since then we've defined them all, so\nthe kmalloc caches need to mark themselves as whitelisted.\n\nPatch 1 leaves unmarked things whitelisted so we can progressively\ntighten the restriction and have a bisectable series. (i.e. if there\nis something wrong with one of the whitelists in the series, it will\nbisect to that one, not the one that removes the global whitelist from\npatch 1.)\n\n-Kees","headers":{"Return-Path":"<netdev-owner@vger.kernel.org>","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=google.com header.i=@google.com\n\theader.b=\"dy4Z/0qZ\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=chromium.org header.i=@chromium.org\n\theader.b=\"cAQFFeze\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xylSr0tChz9t4Z\n\tfor <patchwork-incoming@ozlabs.org>;\n\tFri, 22 Sep 2017 04:27:08 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751803AbdIUS0r (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tThu, 21 Sep 2017 14:26:47 -0400","from mail-io0-f173.google.com ([209.85.223.173]:50451 \"EHLO\n\tmail-io0-f173.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751621AbdIUS0p (ORCPT\n\t<rfc822;netdev@vger.kernel.org>); Thu, 21 Sep 2017 14:26:45 -0400","by mail-io0-f173.google.com with SMTP id w94so12871382ioi.7\n\tfor <netdev@vger.kernel.org>; Thu, 21 Sep 2017 11:26:45 -0700 (PDT)","by 10.107.178.131 with HTTP; Thu, 21 Sep 2017 11:26:43 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=google.com; s=20161025;\n\th=mime-version:sender:in-reply-to:references:from:date:message-id\n\t:subject:to:cc;\n\tbh=3ee7/OmumcvfvMLGtr7owjKASU77O1jk6gLucUEr70U=;\n\tb=dy4Z/0qZ6XPFJG2PucRZICwWnSSLFbBaLMPHZKYxfC9AkDhgOqpdcQA96NWmcWFicR\n\t4Vud4KTHxH/OrO150jqgbiBLXgUaHifmqFkiyjYLpoenEm6OeVo9YmckmdP1b4PC9LWU\n\tP4iG+VS342Ql4Jc9Ado02DCi8aLWepOx8laBkQ9tac2QwrfBSdxRDCCxrj4PP1i+JHUt\n\tsu19kZqG2/cj7DXJrPeyzgOvf0i55XpF72xs9MNdioyY95F4aFw/KA8rwfGwgUEl4pI3\n\t/cVSyCQFEIIl6FLliJYX8GufnC3FUIN/LEM+QLIEcaKZdKoneCelgpLemaFbtjZNg2+t\n\tT8oA==","v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=chromium.org; s=google;\n\th=mime-version:sender:in-reply-to:references:from:date:message-id\n\t:subject:to:cc;\n\tbh=3ee7/OmumcvfvMLGtr7owjKASU77O1jk6gLucUEr70U=;\n\tb=cAQFFezeFtLGtdqAeLGPoGBLOyiYMd/V3XnWVrxtX/KnAxcrTY9EpYkfaXHGNipSLa\n\t3eA8tmKuM680YDtNQN+q/Cnd3nK845AG6o/Gs4CY4xWxWJCjnkFxYzvLZKs02w3qp+Ws\n\tI01TFJxSDltofSJ3bBd7FCEfZF49EyLBtXtSE="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:sender:in-reply-to:references:from\n\t:date:message-id:subject:to:cc;\n\tbh=3ee7/OmumcvfvMLGtr7owjKASU77O1jk6gLucUEr70U=;\n\tb=XChgUTwagK8pS9Qaw56PYxgwTY00T6qfEohL+z/KfIZ84eGZ+AOBI3X9SDl4fFOiF7\n\tb7NGN1k8gsUb5OAwc0vdq6jstUN4lqGdKYy1i6cj25Vfs+Qj0HJ86v+E2Tn3QYp5yg19\n\tpwi37P/ZaN2EhBvj74Fg+jU4xrhH7SSc0BkXR6NZqG1oTsbvHqgT7NdtGDJo4w6XLRNi\n\tYr64QhVCs4fCQqzYguEyvWIPWSFpJhFNSos6lBb3IpoSObpR1Ky+XcQzxdwDjMcrFotv\n\tgobKFAsZY3TNPYElUcisgPcJuSUc9Y7k2EqyTd9DkrGVt6CjBcNXXTtEFx0EMM7K5jDo\n\tjOiw==","X-Gm-Message-State":"AHPjjUhMF2C5SJ6yMBEkaOe6Rl3I9mAwgJJTgfAKrOJwgv10kKKPan/q\n\t+wnJMWYGCe1Pk1IwHdLocfWWgUQiXEfVZ1gx7QN7/Q==","X-Google-Smtp-Source":"AOwi7QDYwP7eE4mDf5goXzs9ki3D4LWEv5+mHfuWw/eR9qwbSXyZldmTkauuKiD9Pxh/JSEm30WuGCgTu6+ab6ws73U=","X-Received":"by 10.107.137.74 with SMTP id l71mr469923iod.186.1506018404799; \n\tThu, 21 Sep 2017 11:26:44 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<alpine.DEB.2.20.1709211102320.14742@nuc-kabylake>","References":"<1505940337-79069-1-git-send-email-keescook@chromium.org>\n\t<1505940337-79069-4-git-send-email-keescook@chromium.org>\n\t<alpine.DEB.2.20.1709211024120.14427@nuc-kabylake>\n\t<CAGXu5j+X6dWCGocG=P7pszTY-5OZ6Jmp-RsnDKox75M5rmVe4g@mail.gmail.com>\n\t<alpine.DEB.2.20.1709211102320.14742@nuc-kabylake>","From":"Kees Cook <keescook@chromium.org>","Date":"Thu, 21 Sep 2017 11:26:43 -0700","X-Google-Sender-Auth":"oUNdyF0Fco1OMzmGI2omR2BaWag","Message-ID":"<CAGXu5jKqWShVMqm6-moqgO7JUaJuFxw-9mMKak+WG1HgNJqc1Q@mail.gmail.com>","Subject":"Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc\n\tcaches as usercopy caches","To":"Christopher Lameter <cl@linux.com>","Cc":"LKML <linux-kernel@vger.kernel.org>, David Windsor <dave@nullcore.net>,\n\tPekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>,\n\tJoonsoo Kim <iamjoonsoo.kim@lge.com>,\n\tAndrew Morton <akpm@linux-foundation.org>,\n\tLinux-MM <linux-mm@kvack.org>, linux-xfs@vger.kernel.org,\n\t\"linux-fsdevel@vger.kernel.org\" <linux-fsdevel@vger.kernel.org>,\n\tNetwork Development <netdev@vger.kernel.org>,\n\t\"kernel-hardening@lists.openwall.com\" \n\t<kernel-hardening@lists.openwall.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<netdev.vger.kernel.org>","X-Mailing-List":"netdev@vger.kernel.org"}}]