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=-13.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham 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 718B4C433E0 for ; Tue, 23 Jun 2020 06:45:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 30D8F2072E for ; Tue, 23 Jun 2020 06:45:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="m6U0Skvb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 30D8F2072E 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 AF6686B0005; Tue, 23 Jun 2020 02:45:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A7FA66B0006; Tue, 23 Jun 2020 02:45:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9483F6B0007; Tue, 23 Jun 2020 02:45:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0008.hostedemail.com [216.40.44.8]) by kanga.kvack.org (Postfix) with ESMTP id 7AB366B0005 for ; Tue, 23 Jun 2020 02:45:24 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 04818824805A for ; Tue, 23 Jun 2020 06:45:24 +0000 (UTC) X-FDA: 76959540168.23.note48_52173aa26e39 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id D2E5537613 for ; Tue, 23 Jun 2020 06:45:23 +0000 (UTC) X-HE-Tag: note48_52173aa26e39 X-Filterd-Recvd-Size: 5666 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Tue, 23 Jun 2020 06:45:23 +0000 (UTC) Received: by mail-qv1-f46.google.com with SMTP id e2so9178317qvw.7 for ; Mon, 22 Jun 2020 23:45:23 -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=kqrm6H9MAMConNZ8UsM9qxabxTYbRgGIA2rshZa0MPA=; b=m6U0SkvbfCx+aJ15SURzgsyxJCOijpaWE0r9HqByYkH9pHhR+0vnK5q2qgXCGlxySX OPTVBuDQ7qz8y4dtxFnR7HCrtqpz3y3WzDy3tavMV2X1oROY9kSCOQm0+rcAfQH6ri2f P45Cy8mruOipyzi3AFTGufdNSwYYm0jDUffAm5ZebrlXgXFJC32DoRi2TYFbU9w3xW4N e4lqkY3ocPAkuGku4MCsD8M/8OEpZYJUhUc2PqXwmSjPbHZSS3/XuJD5ZZRBbly9LqdX p5EDB/hBueouJvSCPFbx41qZCQWwDtcFDD4FUICU6cIBXOodXfir1wGesI1NVABRXE7Z lilQ== 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=kqrm6H9MAMConNZ8UsM9qxabxTYbRgGIA2rshZa0MPA=; b=YKIs/339lE0uNOV76kVLnixGjHAoMAukDt13jZvftWlYKS8T/7NIY7QQ+JHdbpvZAM WL059/x4tzEC+L9IpNpRfPk0AouCT7Udsoa8LiL1jV0IaN8pOC8E1b+VXW1/ZWjGGCck mTXqcJhTylPwAShy7/lZ0Bkl8G7A3koNXX4vEqDJ/bbI6FzWA17Kgo/tJ1X7CY/B08qo aAqEaCElZ/n84zGFjMe8Krllmqw0oIsBW8kpxpZFBReD39LVj3Xe/0cpfrVpkgT0xgC/ lLD9dwKsmsIo32ZNlJqgN2N1KtPdKK8a8gSdlMNCoV15qvYKIf03LyVUyhnU50bbQte9 OEiA== X-Gm-Message-State: AOAM533aZYt5IjcIYIjFO6BqNXS5oDRqQRK1Yynjfpp89xIJIzvb51ol ZnKR0WhWC4ClTOKijK5/gxY6PkdEgDHZf+wtSC5V/w== X-Google-Smtp-Source: ABdhPJyz5MHotfH74zsF2cIt/ICAEYZJGfP7l9CZ3yW+Cm9v5MJLb86WWbFplOD8DY6u/uAQ8ctWBtPOwyJ4rEFGuJ0= X-Received: by 2002:ad4:4868:: with SMTP id u8mr25497586qvy.34.1592894722434; Mon, 22 Jun 2020 23:45:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dmitry Vyukov Date: Tue, 23 Jun 2020 08:45:11 +0200 Message-ID: Subject: Re: Kernel hardening project suggestion: Normalizing ->ctor slabs and TYPESAFE_BY_RCU slabs To: Jann Horn Cc: Kernel Hardening , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Linux-MM , Andrey Konovalov , Will Deacon , kasan-dev , Kees Cook , Alexander Potapenko , Marco Elver Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: D2E5537613 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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, Jun 23, 2020 at 8:26 AM Jann Horn wrote: > > Hi! > > Here's a project idea for the kernel-hardening folks: > > The slab allocator interface has two features that are problematic for > security testing and/or hardening: > > - constructor slabs: These things come with an object constructor > that doesn't run when an object is allocated, but instead when the > slab allocator grabs a new page from the page allocator. This is > problematic for use-after-free detection mechanisms such as HWASAN and > Memory Tagging, which can only do their job properly if the address of > an object is allowed to change every time the object is > freed/reallocated. (You can't change the address of an object without > reinitializing the entire object because e.g. an empty list_head > points to itself.) > > - RCU slabs: These things basically permit use-after-frees by design, > and stuff like ASAN/HWASAN/Memory Tagging essentially doesn't work on > them. > > > It would be nice to have a config flag or so that changes the SLUB > allocator's behavior such that these slabs can be instrumented > properly. Something like: > > - Let calculate_sizes() reserve space for an rcu_head on each object > in TYPESAFE_BY_RCU slabs, make kmem_cache_free() redirect to > call_rcu() for these slabs, and remove most of the other > special-casing, so that KASAN can instrument these slabs. > - For all constructor slabs, let slab_post_alloc_hook() call the > ->ctor() function on each allocated object, so that Memory Tagging and > HWASAN will work on them. Hi Jann, Both things sound good to me. I think we considered doing the ctor's change with KASAN, but we did not get anywhere. The only argument against it I remember now was "performance", but it's not that important if this mode is enabled only with KASAN and other debugging tools. Performance is definitely not as important as missing bugs. The additional code complexity for ctors change should be minimal. The rcu change would also be useful, but I would assume it will be larger. Please add them to [1], that's KASAN laundry list. +Alex, Marco, will it be useful for KFENCE [2] as well? Do ctors/rcu affect KFENCE? Will we need any special handling for KFENCE? I assume it will also be useful for KMSAN b/c we can re-mark objects as uninitialized only after they have been reallocated. [1] https://bugzilla.kernel.org/buglist.cgi?bug_status=__open__&component=Sanitizers&list_id=1063981&product=Memory%20Management [2] https://github.com/google/kasan/commits/kfence