Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1031191pxk; Fri, 25 Sep 2020 04:34:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzkmAiRjMExUzasflbLK5NixbPWllN+njLlftuUH/pfQQ10jsYQWPI+W/qkGuAtwcaxaiZd X-Received: by 2002:aa7:c70a:: with SMTP id i10mr828855edq.218.1601033686385; Fri, 25 Sep 2020 04:34:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601033686; cv=none; d=google.com; s=arc-20160816; b=thwp4hRJ+XFufSGz55g02IRKiIiNCoDQrm2dcLtbjJQzOvdiUupwbCw+CwfCH+JJih fYWXh1bA7OX+R0eJi90cUVbCAmf4OK9cnCaOwJkhYOxN1sVqzP+k3YbYg1tcXpyq7oZU Xktc47gTyTyqwp1B/A9smcno4DaqeJ64/gbE33DgNKwZFS8J0SJJyi3LeQ7t4foRurD0 7mR9p3sbDL1OjNQdtPmlAFazLn4dkW0HWEC51dBr5A95SsOzA7VUEsi+aNSEDu8aX+R+ b0x7M4ctVNLn7Ss+5L5vBP3Vv68fDKBP1QUqii2f4hKhCL1Kyk17rwGKEOkyU2NGRquZ F54Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=6L8pDz+HxatuOD/RjMAAdgwqh+b4jciwbLlL8vlXkeA=; b=Q0zKkXvaE41jk7rDJO8UQBns890vlNwLnzsVRRKeqWOC7y5aSHfHGT75g8wy+VeZhz wxwOvKrKLshdXCbpNC0FTA0gSyAcqZSNK3wPad0LliYf39u5UEAiCJC18MVZNg8MmdAa kYqwJHOuxwJvV46ntxIjXNEjFUOpJlpEY0qz2uGlOWiKknydZtfVZwHB/lP4E/yQR7mz wYkwo44m0u3eX1StGC7R8DflcGXMV0hp7ZkdGbX1x89qzf05FDRdA+itTl5DPrV5HtNM Y6pcGPcWbzLT2qL859ARUxQ6RzCcpqZUgA/rn1MmAffuoPwFAKHHjg2/ThrS8gHeHptO bXTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=qyHbJgNn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lx24si1557678ejb.89.2020.09.25.04.34.22; Fri, 25 Sep 2020 04:34:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=qyHbJgNn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728056AbgIYLcC (ORCPT + 99 others); Fri, 25 Sep 2020 07:32:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726990AbgIYLcB (ORCPT ); Fri, 25 Sep 2020 07:32:01 -0400 Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E44BC0613CE for ; Fri, 25 Sep 2020 04:32:01 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id h17so1979111otr.1 for ; Fri, 25 Sep 2020 04:32:01 -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=6L8pDz+HxatuOD/RjMAAdgwqh+b4jciwbLlL8vlXkeA=; b=qyHbJgNndjOJTaIgRnJQ6gdz3KVViOFrAgXDGuXJJIRD74pqZXl32ezx/nLKfU26eO 4Sswiyv+wYx+68aCOYEcsAZf3hLxli00w3yhK/RaeNtOxUrc10pokEGeU+s1NS9L342a f/3qUcxxVICL9wVpKmpyDNMssvgh9Q51lddnuQkfdLh0ATuhFv3NzEnuvvXUTsOLsvgO YJLBGwF8305u0itBfxkYCF5CDWafOUXiMyTZvcIvDk2rDy10zKMmhaH5F/2Ze2kOAEPI at+QdWNp6iNyaX5chYaA3CG+ThU646hbW4DslUpQHdVbrXIUHwwyE7WKMgtzG5rLJb2I 29cw== 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=6L8pDz+HxatuOD/RjMAAdgwqh+b4jciwbLlL8vlXkeA=; b=JvUGoifaVABy9lcyRg3j8F0/BZ7aTEJbJ90TOHklEdLKLeqVCVgqzGk0dewkbV5j+c 3VJSy7k5fc8tZ0ORWLjlOaSv5f0fXeiAQc8uVjWWciAXmyOdMIDvXKUgt7UZGGzVn3Iz Pvp7WvIymr9xeobiZV+tdY771+tMOP9eGgYzLQ4pSQum7TCMGgfPWALJ9hyrd/ZMAVcZ ajO8LqjQS9nMFojiRiOYgP639WxNA0ppO/I2Y+9KwHwE4bE9pI1RjsWrELbkSJb7acTO aoEKwNWZIRMLYfTEslC/WtcY/VdHbGxJ+t8/wuVaML26Xs6l76kz6X5rMkklBdH4RaEj QY0w== X-Gm-Message-State: AOAM5311atymf527VByB7u6KXF56zKWpJUH83PmAW1XgYzHl/HidHIbt vPqjeem80Xkw6lSfojdzAYX3HoIqsuM3raVnIIX+9g== X-Received: by 2002:a9d:66a:: with SMTP id 97mr2621626otn.233.1601033519970; Fri, 25 Sep 2020 04:31:59 -0700 (PDT) MIME-Version: 1.0 References: <20200921132611.1700350-2-elver@google.com> <20200925112328.10057-1-sjpark@amazon.com> In-Reply-To: <20200925112328.10057-1-sjpark@amazon.com> From: Marco Elver Date: Fri, 25 Sep 2020 13:31:48 +0200 Message-ID: Subject: Re: [PATCH v3 01/10] mm: add Kernel Electric-Fence infrastructure To: SeongJae Park Cc: Andrew Morton , Alexander Potapenko , Mark Rutland , Hillf Danton , "open list:DOCUMENTATION" , Peter Zijlstra , Catalin Marinas , Dave Hansen , Linux Memory Management List , Eric Dumazet , "H. Peter Anvin" , Christoph Lameter , Will Deacon , Jonathan Corbet , "the arch/x86 maintainers" , kasan-dev , Ingo Molnar , Vlastimil Babka , David Rientjes , Andrey Ryabinin , Kees Cook , "Paul E. McKenney" , Jann Horn , Andrey Konovalov , Borislav Petkov , Andy Lutomirski , Jonathan Cameron , Thomas Gleixner , Dmitry Vyukov , Linux ARM , Greg Kroah-Hartman , LKML , Pekka Enberg , Joonsoo Kim Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 25 Sep 2020 at 13:24, 'SeongJae Park' via kasan-dev wrote: > > On Mon, 21 Sep 2020 15:26:02 +0200 Marco Elver wrote: > > > From: Alexander Potapenko > > > > This adds the Kernel Electric-Fence (KFENCE) infrastructure. KFENCE is a > > low-overhead sampling-based memory safety error detector of heap > > use-after-free, invalid-free, and out-of-bounds access errors. > > > > KFENCE is designed to be enabled in production kernels, and has near > > zero performance overhead. Compared to KASAN, KFENCE trades performance > > for precision. The main motivation behind KFENCE's design, is that with > > enough total uptime KFENCE will detect bugs in code paths not typically > > exercised by non-production test workloads. One way to quickly achieve a > > large enough total uptime is when the tool is deployed across a large > > fleet of machines. > > > > KFENCE objects each reside on a dedicated page, at either the left or > > right page boundaries. The pages to the left and right of the object > > page are "guard pages", whose attributes are changed to a protected > > state, and cause page faults on any attempted access to them. Such page > > faults are then intercepted by KFENCE, which handles the fault > > gracefully by reporting a memory access error. To detect out-of-bounds > > writes to memory within the object's page itself, KFENCE also uses > > pattern-based redzones. The following figure illustrates the page > > layout: > > > > ---+-----------+-----------+-----------+-----------+-----------+--- > > | xxxxxxxxx | O : | xxxxxxxxx | : O | xxxxxxxxx | > > | xxxxxxxxx | B : | xxxxxxxxx | : B | xxxxxxxxx | > > | x GUARD x | J : RED- | x GUARD x | RED- : J | x GUARD x | > > | xxxxxxxxx | E : ZONE | xxxxxxxxx | ZONE : E | xxxxxxxxx | > > | xxxxxxxxx | C : | xxxxxxxxx | : C | xxxxxxxxx | > > | xxxxxxxxx | T : | xxxxxxxxx | : T | xxxxxxxxx | > > ---+-----------+-----------+-----------+-----------+-----------+--- > > > > Guarded allocations are set up based on a sample interval (can be set > > via kfence.sample_interval). After expiration of the sample interval, a > > guarded allocation from the KFENCE object pool is returned to the main > > allocator (SLAB or SLUB). At this point, the timer is reset, and the > > next allocation is set up after the expiration of the interval. > > > > To enable/disable a KFENCE allocation through the main allocator's > > fast-path without overhead, KFENCE relies on static branches via the > > static keys infrastructure. The static branch is toggled to redirect the > > allocation to KFENCE. To date, we have verified by running synthetic > > benchmarks (sysbench I/O workloads) that a kernel compiled with KFENCE > > is performance-neutral compared to the non-KFENCE baseline. > > > > For more details, see Documentation/dev-tools/kfence.rst (added later in > > the series). > > > > Reviewed-by: Dmitry Vyukov > > Co-developed-by: Marco Elver > > Signed-off-by: Marco Elver > > Signed-off-by: Alexander Potapenko > > --- > > v3: > > * Reports by SeongJae Park: > > * Remove reference to Documentation/dev-tools/kfence.rst. > > * Remove redundant braces. > > * Use CONFIG_KFENCE_NUM_OBJECTS instead of ARRAY_SIZE(...). > > * Align some comments. > > * Add figure from Documentation/dev-tools/kfence.rst added later in > > series to patch description. > > > > v2: > > * Add missing __printf attribute to seq_con_printf, and fix new warning. > > [reported by kernel test robot ] > > * Fix up some comments [reported by Jonathan Cameron]. > > * Remove 2 cases of redundant stack variable initialization > > [reported by Jonathan Cameron]. > > * Fix printf format [reported by kernel test robot ]. > > * Print (in kfence-#nn) after address, to more clearly establish link > > between first and second stacktrace [reported by Andrey Konovalov]. > > * Make choice between KASAN and KFENCE clearer in Kconfig help text > > [suggested by Dave Hansen]. > > * Document CONFIG_KFENCE_SAMPLE_INTERVAL=0. > > * Shorten memory corruption report line length. > > * Make /sys/module/kfence/parameters/sample_interval root-writable for > > all builds (to enable debugging, automatic dynamic tweaking). > > * Reports by Dmitry Vyukov: > > * Do not store negative size for right-located objects > > * Only cache-align addresses of right-located objects. > > * Run toggle_allocation_gate() after KFENCE is enabled. > > * Add empty line between allocation and free stacks. > > * Add comment about SLAB_TYPESAFE_BY_RCU. > > * Also skip internals for allocation/free stacks. > > * s/KFENCE_FAULT_INJECTION/KFENCE_STRESS_TEST_FAULTS/ as FAULT_INJECTION > > is already overloaded in different contexts. > > * Parenthesis for macro variable. > > * Lower max of KFENCE_NUM_OBJECTS config variable. > > --- > > MAINTAINERS | 11 + > > include/linux/kfence.h | 174 ++++++++++ > > init/main.c | 2 + > > lib/Kconfig.debug | 1 + > > lib/Kconfig.kfence | 63 ++++ > > mm/Makefile | 1 + > > mm/kfence/Makefile | 3 + > > mm/kfence/core.c | 733 +++++++++++++++++++++++++++++++++++++++++ > > mm/kfence/kfence.h | 102 ++++++ > > mm/kfence/report.c | 219 ++++++++++++ > > 10 files changed, 1309 insertions(+) > > create mode 100644 include/linux/kfence.h > > create mode 100644 lib/Kconfig.kfence > > create mode 100644 mm/kfence/Makefile > > create mode 100644 mm/kfence/core.c > > create mode 100644 mm/kfence/kfence.h > > create mode 100644 mm/kfence/report.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index b5cfab015bd6..863899ed9a29 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -9673,6 +9673,17 @@ F: include/linux/keyctl.h > > F: include/uapi/linux/keyctl.h > > F: security/keys/ > > > > +KFENCE > > +M: Alexander Potapenko > > +M: Marco Elver > > +R: Dmitry Vyukov > > +L: kasan-dev@googlegroups.com > > +S: Maintained > > +F: Documentation/dev-tools/kfence.rst > > This patch doesn't introduce this file yet, right? How about using a separate > final patch for MAINTAINERS update? Sure. > Other than that, > > Reviewed-by: SeongJae Park Thanks!