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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 A9694C4363D for ; Tue, 6 Oct 2020 02:16:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 305A820874 for ; Tue, 6 Oct 2020 02:16:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="VSSaWD0W" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 305A820874 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 83B3E6B005C; Mon, 5 Oct 2020 22:16:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EAA96B005D; Mon, 5 Oct 2020 22:16:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 700CD6B0062; Mon, 5 Oct 2020 22:16:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0065.hostedemail.com [216.40.44.65]) by kanga.kvack.org (Postfix) with ESMTP id 3FFF56B005C for ; Mon, 5 Oct 2020 22:16:41 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D25A7180AD806 for ; Tue, 6 Oct 2020 02:16:40 +0000 (UTC) X-FDA: 77339886960.23.force90_380acca271c3 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id AE9DD3760C for ; Tue, 6 Oct 2020 02:16:40 +0000 (UTC) X-HE-Tag: force90_380acca271c3 X-Filterd-Recvd-Size: 5958 Received: from mail-ej1-f65.google.com (mail-ej1-f65.google.com [209.85.218.65]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Tue, 6 Oct 2020 02:16:40 +0000 (UTC) Received: by mail-ej1-f65.google.com with SMTP id a3so15174364ejy.11 for ; Mon, 05 Oct 2020 19:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ifD/jW+MjbtS2EijgQAS4OITv0Z9zRA4cL1N04HQHu4=; b=VSSaWD0WAT8lHVeaIEU8br+ZuZLpGvG3RSgyTiKVEHpRLj5caJa8VuxrOzMMZmi4/I +jc18B7Thyp3/FetZnGQgiu+3jGf71BUbdlYdfQ/sXkO4yIffJZxsNlUT3OTfTYc+V53 s/rD9zQmzH7e/+nYz+ii0l6JB/cgE0XhGNA8YvQrzBYVVZv+tfs+QQFQOzjgU6l2HxUK XgMhDW8lxfC88/jHL1K9CxVfkjKO7y42/ifl50NEIctn5atANq4PIvf9c4TvRkLRtmhv tnJm3J56L+FQTruYZN7URj8QELVaRv71JNVB9HeCWh34hlHaMpNzgxJKGO/gMn3MIfVk OgKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ifD/jW+MjbtS2EijgQAS4OITv0Z9zRA4cL1N04HQHu4=; b=I8jE2Z2xvoXM4r/qY1dDDfQVGjp4Qwb71coLntQMJ++WC/PXvqYIvzZS9HMKbiWBlu XcAqyxLfYLJoPF/n/yT20fUMCEkHTSQeX8Eqd3qyImRmxJeoj+bP/Gog1DkEzRGE8TAB VD1Y6JbT7Mc6haHkLnL5lzhS31cuwRSYYhuDuZiypdO+IGKvJPmfE1ja2lD4AWBZRWZB QXFhulzI34rjDrwO9u24uV4SjdII/tNkLX1B1wfhso6p56gpKVLzVASKJFay3PYagdG9 SIfFDdna7JIeLUK03SuYCNPnzQs24Wxe/+N4Yke/0lFdxdzFYqoBqSdEW29qayyDl12I DPkQ== X-Gm-Message-State: AOAM531Qsgd29u2nVrXZTKAUjAHawupYLpED3ILvZhaiaraH/SwkREYi pD+jJD/Q7i+COIFfpRjCDQECXc9hhuqM2LBSPwVi5g== X-Google-Smtp-Source: ABdhPJwxo4AWg8S4Ze5aWA5+V2LLRVib5nWtluQURuOp9DVBriFY+LJHVl4ksm/ZNF2+q+SZWj8S0GCu3SVtK3S+aco= X-Received: by 2002:a17:906:fcae:: with SMTP id qw14mr2849150ejb.537.1601950598646; Mon, 05 Oct 2020 19:16:38 -0700 (PDT) MIME-Version: 1.0 References: <20200929183513.380760-1-alex.popov@linux.com> <91d564a6-9000-b4c5-15fd-8774b06f5ab0@linux.com> <20201006004414.GP20115@casper.infradead.org> <202010051905.62D79560@keescook> In-Reply-To: <202010051905.62D79560@keescook> From: Jann Horn Date: Tue, 6 Oct 2020 04:16:12 +0200 Message-ID: Subject: Re: [PATCH RFC v2 0/6] Break heap spraying needed for exploiting use-after-free To: Kees Cook Cc: Matthew Wilcox , 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 Content-Type: text/plain; charset="UTF-8" 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 6, 2020 at 4:09 AM Kees Cook wrote: > 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) Yes, but slab_merge still normally frees slab pages to the page allocator. > 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? Well, a bit of plumbing, at least. You'd need to teach the compiler frontend to grab type names from sizeof() and stuff that type information somewhere, e.g. by generating an extra function argument referring to the type, or something like that. Could be as simple as a reference to a bss section variable that encodes the type in the name, and the linker already has the logic to automatically deduplicate those across compilation units - that way, on the compiler side, a pure frontend plugin might do the job?