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=-4.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 3B2A8C46466 for ; Tue, 6 Oct 2020 02:09:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 979E62076B for ; Tue, 6 Oct 2020 02:09:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="jDfIYFTb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 979E62076B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9FACF6B005C; Mon, 5 Oct 2020 22:09:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 984128E0001; Mon, 5 Oct 2020 22:09:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84B8C6B0062; Mon, 5 Oct 2020 22:09:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id 4F3616B005C for ; Mon, 5 Oct 2020 22:09:29 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CB5071F06 for ; Tue, 6 Oct 2020 02:09:28 +0000 (UTC) X-FDA: 77339868816.29.wrist10_52130ed271c3 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 98F29180868CA for ; Tue, 6 Oct 2020 02:09:28 +0000 (UTC) X-HE-Tag: wrist10_52130ed271c3 X-Filterd-Recvd-Size: 5418 Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com [209.85.215.194]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Tue, 6 Oct 2020 02:09:28 +0000 (UTC) Received: by mail-pg1-f194.google.com with SMTP id u24so7123289pgi.1 for ; Mon, 05 Oct 2020 19:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5uyUjU81WTaoePaJ6pjDUCkELEhzyE83H9lRZhP1V5g=; b=jDfIYFTbm5fkMc29R8o9ZHzX7Pte5RCT8w+9F5TNDpMHIl3zGQzp4q/T71oiQgb/Si k1O/y8IqkbJWAFT7y97YeQ6EIsYzITVWj2oBZvzYlLyMjwb8Wu46wKdTHdqb5EdpdpIe 2MJyTF338pNoHuKyl4uFjC7Li4Vt/hvBkHZ6Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5uyUjU81WTaoePaJ6pjDUCkELEhzyE83H9lRZhP1V5g=; b=RUTFIlzNzKIMJQRkmBH506gEyF50En/n57/UxU8BfgmHGoU4irzMj2Sqd0o3RlFayq Dk2AEiG6zbgO97iIO1fgu+afEAbSxYfpjnu3ua8tNZd1/QhwujirbVFcPfH3Cm8T0xlP Xv/ZjFNm7D7uhfmYyKJi6F/Bcu2tUMKN+SGvwY3ik8E/Fv4Czn2DF99n/v5LgZGnK9y+ +AOOlomm6z+rXqoYyyaQRhE5biiTTy+NZM+v9VTsA1yYvawrSogCd3vAkz8newYgGD/J UkQSjI5EL0n6MUVVqBmvbhKInX3KwIHPu9EQaKsELzg8L/QXisrjjZz9dwcq6CAAc43O ZQEQ== X-Gm-Message-State: AOAM531VlxH3tOahR+F5+mSp05WWqpoTuNLca4CsiVwXepQdR1LYmgy+ GWf1UAC1kvlBr76nA8A1HlUk1Q== X-Google-Smtp-Source: ABdhPJw1yy34c+6y9kLpMI11/8Zi779s/k+fdqtafVTUPFWsVg2uuJr39pC14FmoS/i8HTu+80T8OQ== X-Received: by 2002:aa7:8249:0:b029:142:2501:3964 with SMTP id e9-20020aa782490000b029014225013964mr2373840pfn.41.1601950167029; Mon, 05 Oct 2020 19:09:27 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id c9sm941792pgl.92.2020.10.05.19.09.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2020 19:09:25 -0700 (PDT) Date: Mon, 5 Oct 2020 19:09:24 -0700 From: Kees Cook To: Matthew Wilcox Cc: Jann Horn , Alexander Popov , Will Deacon , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Christoph Lameter , 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 Message-ID: <202010051905.62D79560@keescook> References: <20200929183513.380760-1-alex.popov@linux.com> <91d564a6-9000-b4c5-15fd-8774b06f5ab0@linux.com> <20201006004414.GP20115@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201006004414.GP20115@casper.infradead.org> 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, Oct 06, 2020 at 01:44:14AM +0100, 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 ... 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) 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? -- Kees Cook