Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4103469pxk; Tue, 8 Sep 2020 10:46:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzkcnzWSKSFwSu+0/qJvp67jatIwqmDjcMQUECvqxTAWq2Dv5f7OAU5OthqAfiTrFBjZF7I X-Received: by 2002:a50:fb0e:: with SMTP id d14mr112083edq.172.1599587165916; Tue, 08 Sep 2020 10:46:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599587165; cv=none; d=google.com; s=arc-20160816; b=zQMVsF4D/BPdU22zB1rBO9MSQRe2Pa+3DuIUSuetExwxOCG+qmRq59u+OyPVNGB4Nc atf9WXVezBBw2tAP18iMXuqBI8jg1H3ek4ecjUUNVLWeBirjr2mGpSX3NQZHPe76rB8a /8DxWWoogcUb8v5AYzvfKacxMBdwBIm/aiUP1wQKOHAt5XQmZ9jzpmj+iHspQPuUzRDa t4Ag7Xn+IPTC9o5qycZKzyvXYb3ITiWmZ3HIRX4lNGFU645+xagOPsIIxnbVdfeS6aDF 3OAJxKHhvDJJc2+e6DaoPzMmgDdVP42cLeDugQR3nhxXuQiW70AIt3ItFuLWDZw1Nfbb NVYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=25SuQDI0eyCRm9y5WDHzplEK9oGtQL3VKe10BEOjmTA=; b=ksqS/AtYnqdyMOFQZvivPgw1CW3aVNI5wWE4kP+RTGRtghiurraNWuu8gMPiJFr272 nvUH+EnaXilJ4p29PmlavjYCTi1fumfP4ek4bvM7OO8vhhIfSTYqequz5SYAnzZXTaJR kWuC802bCo4CY84VCQehpIT4nyP2RE5xVe16IPYJk9ub64MeW1hNyX2MtGVDs7oL52TJ UUfL2S+Fj66eBAOcfyX6d5K3KUCgSkpihGlob2HXIIRZCOkAyWue7XggAYSGfQpBiBFl XGNWwEOjngF3og19p5tpRPJ+1MNKvRFySMPblhLim+l2GWg3lRkDFAj0RYwkI6OdDPSU k0dA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=QPX3it+b; 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 e12si12188274ejq.375.2020.09.08.10.45.42; Tue, 08 Sep 2020 10:46:05 -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=QPX3it+b; 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 S1731656AbgIHRn5 (ORCPT + 99 others); Tue, 8 Sep 2020 13:43:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731664AbgIHQOE (ORCPT ); Tue, 8 Sep 2020 12:14:04 -0400 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 70E2EC0617B9 for ; Tue, 8 Sep 2020 05:16:22 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id q9so17091120wmj.2 for ; Tue, 08 Sep 2020 05:16:22 -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:content-transfer-encoding; bh=25SuQDI0eyCRm9y5WDHzplEK9oGtQL3VKe10BEOjmTA=; b=QPX3it+b0HCvDkvbnLXnuah4CoH16gftRJ7806vrwP3qNieZtYGGzWOWb5H6s2Ymo6 tFciYxxHwZ+bLk25IzxWbtHz0zL7hPxojHfBsUJqxOPoVKqSYMw4s5Jhs4CWSe+lLKvZ c5AwWr450MpqcX6CXpFhLMMNrVYkQ9Fjd8nqLWMfFi9LnzsfdtWd0LpKQYtzz+NCxHB3 J637fA5b93NLgh+gh4KvKv3RMjqzd73wNSnuCBKM/un+6MXqTcJ0HEPCNbet4mb1L5NA cKFb0yVJxMPcpuUS6t+uXVXwP2CwZFGY4q8U86OqXN4i0oaciML3l3t5SgA2Rsr+bZIa dFfg== 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:content-transfer-encoding; bh=25SuQDI0eyCRm9y5WDHzplEK9oGtQL3VKe10BEOjmTA=; b=boefQ8avXQ0E42bqc2BFMAzZoV8ybYrVJvNGYhi189YPd5vouqN9MmBrP0Tha5RFo1 bVKZnvQcjJ1IbdQiAvrqAvQXSC7KO9m8rZRIUtXyvecCkZcDl3xIOhqCKiddiGIyfWA4 4PdUwPr4kn51e34P2gpHdKAIZ00Pqzu10qSQpGepPXGI7PetV+l4rSharXpPaAu/93/R fcB1+SsIHKovrAqELN1M3DMpPn1uRfj7r+JLH53ClGQCAS4tQQjPF9ElQeS1FrA+lig+ FL/31kYRTVIM2nDEp9mRDxiK8CYafuIhanksD2JRduy38/qntsscabjixCvwBauTcCss dKpA== X-Gm-Message-State: AOAM533GZAKh1VDluVY3uG07/aHmOgQtgQ9JXW+NM5LwEG0huFdyJiO2 pduAP81gJPGjEtFa0ZMWWGhShXZDv/lbhRTm2fkThw== X-Received: by 2002:a1c:105:: with SMTP id 5mr4078883wmb.175.1599567380842; Tue, 08 Sep 2020 05:16:20 -0700 (PDT) MIME-Version: 1.0 References: <20200907134055.2878499-1-elver@google.com> <4dc8852a-120d-0835-1dc4-1a91f8391c8a@suse.cz> In-Reply-To: <4dc8852a-120d-0835-1dc4-1a91f8391c8a@suse.cz> From: Alexander Potapenko Date: Tue, 8 Sep 2020 14:16:09 +0200 Message-ID: Subject: Re: [PATCH RFC 00/10] KFENCE: A low-overhead sampling-based memory safety error detector To: Vlastimil Babka Cc: Marco Elver , Andrew Morton , Catalin Marinas , Christoph Lameter , David Rientjes , Joonsoo Kim , Mark Rutland , Pekka Enberg , "H. Peter Anvin" , paulmck@kernel.org, Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , dave.hansen@linux.intel.com, Dmitriy Vyukov , Eric Dumazet , Greg Kroah-Hartman , Ingo Molnar , Jann Horn , Jonathan Corbet , Kees Cook , Peter Zijlstra , Qian Cai , Thomas Gleixner , Will Deacon , "the arch/x86 maintainers" , linux-doc@vger.kernel.org, LKML , kasan-dev , linux-arm-kernel@lists.infradead.org, Linux Memory Management List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Toggling a static branch is AFAIK quite disruptive (PeterZ will probably = tell > you better), and with the default 100ms sample interval, I'd think it's n= ot good > to toggle it so often? Did you measure what performance would you get, if= the > static key was only for long-term toggling the whole feature on and off (= boot > time or even runtime), but the decisions "am I in a sample interval right= now?" > would be normal tests behind this static key? Thanks. 100ms is the default that we use for testing, but for production it should be fine to pick a longer interval (e.g. 1 second or more). We haven't noticed any performance impact with neither 100ms nor bigger val= ues. Regarding using normal branches, they are quite expensive. E.g. at some point we used to have a branch in slab_free() to check whether the freed object belonged to KFENCE pool. When the pool address was taken from memory, this resulted in some non-zero performance penalty. As for enabling the whole feature at runtime, our intention is to let the users have it enabled by default, otherwise someone will need to tell every machine in the fleet when the feature is to be enabled. > > > We have verified by running synthetic benchmarks (sysbench I/O, > > hackbench) that a kernel with KFENCE is performance-neutral compared to > > a non-KFENCE baseline kernel. > > > > KFENCE is inspired by GWP-ASan [1], a userspace tool with similar > > properties. The name "KFENCE" is a homage to the Electric Fence Malloc > > Debugger [2]. > > > > For more details, see Documentation/dev-tools/kfence.rst added in the > > series -- also viewable here: > > > > https://raw.githubusercontent.com/google/kasan/kfence/Documentati= on/dev-tools/kfence.rst > > > > [1] http://llvm.org/docs/GwpAsan.html > > [2] https://linux.die.net/man/3/efence > > > > Alexander Potapenko (6): > > mm: add Kernel Electric-Fence infrastructure > > x86, kfence: enable KFENCE for x86 > > mm, kfence: insert KFENCE hooks for SLAB > > mm, kfence: insert KFENCE hooks for SLUB > > kfence, kasan: make KFENCE compatible with KASAN > > kfence, kmemleak: make KFENCE compatible with KMEMLEAK > > > > Marco Elver (4): > > arm64, kfence: enable KFENCE for ARM64 > > kfence, lockdep: make KFENCE compatible with lockdep > > kfence, Documentation: add KFENCE documentation > > kfence: add test suite > > > > Documentation/dev-tools/index.rst | 1 + > > Documentation/dev-tools/kfence.rst | 285 +++++++++++ > > MAINTAINERS | 11 + > > arch/arm64/Kconfig | 1 + > > arch/arm64/include/asm/kfence.h | 39 ++ > > arch/arm64/mm/fault.c | 4 + > > arch/x86/Kconfig | 2 + > > arch/x86/include/asm/kfence.h | 60 +++ > > arch/x86/mm/fault.c | 4 + > > include/linux/kfence.h | 174 +++++++ > > init/main.c | 2 + > > kernel/locking/lockdep.c | 8 + > > lib/Kconfig.debug | 1 + > > lib/Kconfig.kfence | 70 +++ > > mm/Makefile | 1 + > > mm/kasan/common.c | 7 + > > mm/kfence/Makefile | 6 + > > mm/kfence/core.c | 730 +++++++++++++++++++++++++++ > > mm/kfence/kfence-test.c | 777 +++++++++++++++++++++++++++++ > > mm/kfence/kfence.h | 104 ++++ > > mm/kfence/report.c | 201 ++++++++ > > mm/kmemleak.c | 11 + > > mm/slab.c | 46 +- > > mm/slab_common.c | 6 +- > > mm/slub.c | 72 ++- > > 25 files changed, 2591 insertions(+), 32 deletions(-) > > create mode 100644 Documentation/dev-tools/kfence.rst > > create mode 100644 arch/arm64/include/asm/kfence.h > > create mode 100644 arch/x86/include/asm/kfence.h > > 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-test.c > > create mode 100644 mm/kfence/kfence.h > > create mode 100644 mm/kfence/report.c > > > --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg