From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33221C4727D for ; Tue, 6 Oct 2020 08:32:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B936020789 for ; Tue, 6 Oct 2020 08:32:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B936020789 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 19FDF6B005C; Tue, 6 Oct 2020 04:32:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 151696B005D; Tue, 6 Oct 2020 04:32:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03E8B6B0062; Tue, 6 Oct 2020 04:32:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id CCCD66B005C for ; Tue, 6 Oct 2020 04:32:53 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 681FB362A for ; Tue, 6 Oct 2020 08:32:53 +0000 (UTC) X-FDA: 77340835026.07.cat53_4516e14271c5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id 44CB51803F9B2 for ; Tue, 6 Oct 2020 08:32:53 +0000 (UTC) X-HE-Tag: cat53_4516e14271c5 X-Filterd-Recvd-Size: 3681 Received: from gentwo.org (gentwo.org [3.19.106.255]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Tue, 6 Oct 2020 08:32:52 +0000 (UTC) Received: by gentwo.org (Postfix, from userid 1002) id 2990640ABD; Tue, 6 Oct 2020 08:32:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 26F2140ABC; Tue, 6 Oct 2020 08:32:52 +0000 (UTC) Date: Tue, 6 Oct 2020 08:32:52 +0000 (UTC) From: Christopher Lameter X-X-Sender: cl@www.lameter.com To: Matthew Wilcox cc: Jann Horn , Alexander Popov , Kees Cook , 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: <20201006004414.GP20115@casper.infradead.org> Message-ID: References: <20200929183513.380760-1-alex.popov@linux.com> <91d564a6-9000-b4c5-15fd-8774b06f5ab0@linux.com> <20201006004414.GP20115@casper.infradead.org> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 6 Oct 2020, Matthew Wilcox wrote: > On Tue, Oct 06, 2020 at 12:56:33AM +0200, Jann Horn wrote: > > It seems to me like, if you want to make UAF exploitation harder at > > the heap allocator layer, you could do somewhat more effective things > > with a probably much smaller performance budget. Things like > > preventing the reallocation of virtual kernel addresses with different > > types, such that an attacker can only replace a UAF object with > > another object of the same type. (That is not an idea I like very much > > either, but I would like it more than this proposal.) (E.g. some > > browsers implement things along those lines, I believe.) > > The slab allocator already has that functionality. We call it > 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 ... TYPESAFE functionality switches a lot of debugging off because that also allows speculative accesses to the object after it was freed (requires for RCU safeness because the object may be freed in an RCU period where it is still accessed). I do not think you would like that.