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 3A419C4727D for ; Tue, 6 Oct 2020 00:49:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D13372076B for ; Tue, 6 Oct 2020 00:49:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="deEOQpGo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D13372076B 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 E50B16B005C; Mon, 5 Oct 2020 20:49:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD9216B005D; Mon, 5 Oct 2020 20:49:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA0FF6B0062; Mon, 5 Oct 2020 20:49:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id 9B6816B005C for ; Mon, 5 Oct 2020 20:49:28 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 38047181AE873 for ; Tue, 6 Oct 2020 00:49:28 +0000 (UTC) X-FDA: 77339667216.26.club71_520ac65271c2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 139111804B669 for ; Tue, 6 Oct 2020 00:49:28 +0000 (UTC) X-HE-Tag: club71_520ac65271c2 X-Filterd-Recvd-Size: 5290 Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Tue, 6 Oct 2020 00:49:27 +0000 (UTC) Received: by mail-ed1-f67.google.com with SMTP id b12so11528302edz.11 for ; Mon, 05 Oct 2020 17:49:27 -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=DSqKb3Tej8m7nFeWjbSYdo/k6NG+xT3qX97daJHfAaE=; b=deEOQpGoKw7XNYSPULzK/Fx+6FgNXN/khjYZmJenTlrPkh3dV8pR9GRMbNMshg3WBV mIhmaC0prowNnpBBfAOgciFl8Aodl0rSQD0jjxo98zbVcb/lVK/w4xzZ8RH7ut5R65D4 8in1ydpN21OQa+pm2/egla8YAjlb0ivT9qFVlicuCHeu1OSW7e91KAVeVD8rfu51aRDF qMQv329ZsWOgNyP21r8aTq6vFJInOWaztNfk0KHDhN4hKlc+rb6zcKrDeoSYKitO8zvC oTJCmeqSuf2Nyq1UbdDB7JdyBRZqPMuxwo7izVmribdAB7jmHG8WWxh41wYQuF3rNl4g AM2g== 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=DSqKb3Tej8m7nFeWjbSYdo/k6NG+xT3qX97daJHfAaE=; b=ld2pfDR8XoaoxbIV2DFP2/z+wHs91swAXoIdxPSQGbOl5U2hnNgrAQAramUn0m9es9 CJ+/wAbzYz1vEOtb7ZzgIo4Yhe4dMoxr1kJjt1Rjg8Ze9NAEoOuMt4IWKzpTpstUOalt 5/54nClTyCj5WMFw93iOhDUTxNZZJURtbdT9YOnDRGEZE4Uw4vOchWZa//x0vBMY2VY3 +P41Wr5FOIuNIiZ1Ajx5oAirqrAbmJpqB6i6yTjb0tqX1FsXhYShcz3OewsdvHQI2yeV Ut49TnyCtmDylIUzphNKf0W/bPwO4Zs1A4wX/mt174vGMK1ThD3HFMFntqehford8DEm h42w== X-Gm-Message-State: AOAM531RnfVddhWviCg1e7iGY7lRvzm/KgWm2fcdNnHQ1mQX1ep33lD2 YOlEspBk+f4lRkWK4vcgudyL9F6yvwUojGUyu3a/og== X-Google-Smtp-Source: ABdhPJzX5TIoNNDa3K+sA4F6j+CIm71wUpd29DPTJfqfilZUUFmdG5N8+VeVzCx8F4tg0u5dyUACMyV8sE4qgDYzfPY= X-Received: by 2002:a50:fe98:: with SMTP id d24mr2504183edt.223.1601945366080; Mon, 05 Oct 2020 17:49:26 -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> In-Reply-To: <20201006004414.GP20115@casper.infradead.org> From: Jann Horn Date: Tue, 6 Oct 2020 02:48:59 +0200 Message-ID: Subject: Re: [PATCH RFC v2 0/6] Break heap spraying needed for exploiting use-after-free To: Matthew Wilcox Cc: Alexander Popov , Kees Cook , 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 2:44 AM 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_BY_RCU just forces an RCU grace period before the reallocation; I'm thinking of something more drastic, like completely refusing to give back the memory, or using vmalloc for slabs where that's safe (reusing physical but not virtual addresses across types). And, to make it more effective, something like a compiler plugin to isolate kmalloc(sizeof()) allocations by type beyond just size classes.