Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp102219pxu; Tue, 6 Oct 2020 01:40:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwK6KBZvPqpRpnMQ1m0S3LUStfjegX8sXuUJwuFWxS84eODK+/psvrKEJ4lkygj9USo4AzH X-Received: by 2002:a50:bb0d:: with SMTP id y13mr4352709ede.317.1601973612419; Tue, 06 Oct 2020 01:40:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601973612; cv=none; d=google.com; s=arc-20160816; b=autW83rw09oxOhTaiEPFm16BwkD7azz+ysNvrD0hab6HWAKqf0vD9TDyawG2u+c5wR fI6QWHCsECsbEDzE/otfnbrVAnIoWZHo1+e/SwW8xb6Jjd8PrNqNGIkYWG16k65h4XG7 TiZe7VN9phFee0vU3G0mdqtgONvyryHVBaE/PODuLPmt3RLb4+ufY4AWYRnXj4yPVsTS OfcvU3YORxZOHHdKRTo7oWuZHMvBud0IyfYwxhxFu75xPFoTgKkDSs80wEDT8Em6MWZD QYQuXZYLXwF85O4uUX1psSSMkp0kASA3QHdeI72lrJJfxTsByYdw887QbOn9MuL7NKva diBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=RFesPh/TNVv45QUUwmEg9lGXtkytEHe7dV2VHPbQx3A=; b=qR+kS818MnB7yIfoVmnVOdeHejPWo9n4qbchGhlw/h7HrLptUWRCPI35KouSlSrwdj d4BsAurMttAFtVpML1KRD+ddWTtxMQ44z8zjNnd1efkmSnfJlmkWVr/DfEpeFpW9+/py yoEUZsM+RDfkHt1exvaGxRgd/Gf7iRwXmbI1PHWKDC2+a2f39LLmX4LN7CV9DJpeFkwT Peq+MdJ8cd3S7DjMwD38n5NfSFx8sl3Svtmw30OiP4W1rH4Msctt4uV/VZBWacK2Jyjz KUZbs+R4pGWTS10aP2R0R7Iw/KuR5fl7mcJtjuLWD4PbZHsFVEXwMEz8mtWSHkS1TkX7 exrQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s19si1902406eja.288.2020.10.06.01.39.49; Tue, 06 Oct 2020 01:40:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726105AbgJFIff (ORCPT + 99 others); Tue, 6 Oct 2020 04:35:35 -0400 Received: from gentwo.org ([3.19.106.255]:50346 "EHLO gentwo.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725934AbgJFIfe (ORCPT ); Tue, 6 Oct 2020 04:35:34 -0400 Received: by gentwo.org (Postfix, from userid 1002) id 7989E40ABF; Tue, 6 Oct 2020 08:35:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 76A3540ABE; Tue, 6 Oct 2020 08:35:50 +0000 (UTC) Date: Tue, 6 Oct 2020 08:35:50 +0000 (UTC) From: Christopher Lameter X-X-Sender: cl@www.lameter.com To: Kees Cook cc: Matthew Wilcox , Jann Horn , Alexander Popov , Will Deacon , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Masahiro Yamada , Masami Hiramatsu , Steven Rostedt , Peter Zijlstra , Krzysztof Kozlowski , Patrick Bellasi , David Howells , Eric Biederman , Johannes Weiner , Laura Abbott , Arnd Bergmann , Greg Kroah-Hartman , Daniel Micay , Andrey Konovalov , Pavel Machek , Valentin Schneider , kasan-dev , Linux-MM , Kernel Hardening , kernel list , notify@kernel.org Subject: Re: [PATCH RFC v2 0/6] Break heap spraying needed for exploiting use-after-free In-Reply-To: <202010051905.62D79560@keescook> Message-ID: References: <20200929183513.380760-1-alex.popov@linux.com> <91d564a6-9000-b4c5-15fd-8774b06f5ab0@linux.com> <20201006004414.GP20115@casper.infradead.org> <202010051905.62D79560@keescook> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 5 Oct 2020, Kees Cook wrote: > > TYPESAFE_BY_RCU, but if forcing that on by default would enhance security > > by a measurable amount, it wouldn't be a terribly hard sell ... > > Isn't the "easy" version of this already controlled by slab_merge? (i.e. > do not share same-sized/flagged kmem_caches between different caches) Right. > The large trouble are the kmalloc caches, which don't have types > associated with them. Having implicit kmem caches based on the type > being allocated there would need some pretty extensive plumbing, I > think? Actually typifying those accesses may get rid of a lot of kmalloc allocations and could help to ease the management and control of objects. It may be a big task though given the ubiquity of kmalloc and the need to create a massive amount of new slab caches. This is going to reduce the cache hit rate significantly.