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,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 1E57EC47423 for ; Fri, 2 Oct 2020 07:54:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CE2E820719 for ; Fri, 2 Oct 2020 07:54:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ZImYzlgj" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726282AbgJBHyE (ORCPT ); Fri, 2 Oct 2020 03:54:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725993AbgJBHyD (ORCPT ); Fri, 2 Oct 2020 03:54:03 -0400 Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23FEEC0613E2 for ; Fri, 2 Oct 2020 00:54:03 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id k14so721451edo.1 for ; Fri, 02 Oct 2020 00:54:03 -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=e6vV2mQW9X/bc3rvl043TXcmZeVV1Y9QdMUbU/DoAeE=; b=ZImYzlgjXsFUc2CCMT9j97ZUOzil+3t99KxFvX4NmLd7QCKth6NtxJkTizVZrbxLJl XuvPQrG5tlvHtzGj+IlQKy5HBgv5uBemIZU053zhGAVXxs2OXDmzcmv7i1ITAS9v7aax HfJzfaD+0Uz9InQ58lwv3LPQblvNPk0i+iIhujWGXNEhWqaDtFuS8Zpc+hkUOCx7E9xi WF0YlRjZrwO+Y/k728n8WDQqJ3TnLJJISWx8k2HM9urYCqKo0eZ02BDG/XfaH2eIEA6W nQPGal9DyIq+497MJY0Pfaf3Rge5lwVUdXx+8GDCqnhvOg82rS7CxbgH7Tg5SWvEyt3R iT0g== 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=e6vV2mQW9X/bc3rvl043TXcmZeVV1Y9QdMUbU/DoAeE=; b=N0RA7v8lAA3bbZZcVKKbZ+Pama4GjstaS0ce9B6iHdziyXpMrSI845G/Kx7y3xRC1R hGiJMLnvasF1UUXDmWLkxiwH5X0oZdblu4CLT6bKdqJ7JwonArfZb0KY+aG74iH9FZnj sWZniHPwsRJaJ/an0mOY5zQVN1Gk0oYHH7FTlpdyfR8QDy227bXPLiWyFtOxrkXrkpc1 JwYXX9ahcOmzk1spxRCrPn0IBfsJAgEYRKd0yNiApdIOaEh28ClCxhwHfS9iotD+4TwB 9NvZouCty7Ye6/CRyRa2VMQeWMVlQJgKOlEmETbx0xLtNDSm15xAGREahKfntQ9iJ9FJ eWCg== X-Gm-Message-State: AOAM5337kB9ogVgT8K6b0nnZrCs+lunEevVwNMDI6khPFwKQsnMC6nDo 90t+cfrsaWU1Vo0sfUwDMnEvB4ZZ0zgOgEgfy8Nc/A== X-Google-Smtp-Source: ABdhPJw8JCv+/xESYG7KtHUsTPSjS1wwtCM31dmLgZK5YLiFsgcQliR929HzUjpB/jwncke9ycuFEY9U+TB0Bt5y718= X-Received: by 2002:a05:6402:b0e:: with SMTP id bm14mr1055829edb.259.1601625241408; Fri, 02 Oct 2020 00:54:01 -0700 (PDT) MIME-Version: 1.0 References: <20200929133814.2834621-1-elver@google.com> <20200929133814.2834621-2-elver@google.com> In-Reply-To: From: Jann Horn Date: Fri, 2 Oct 2020 09:53:34 +0200 Message-ID: Subject: Re: [PATCH v4 01/11] mm: add Kernel Electric-Fence infrastructure To: Marco Elver Cc: Andrew Morton , Alexander Potapenko , "H . Peter Anvin" , "Paul E . McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christoph Lameter , Dave Hansen , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jonathan.Cameron@huawei.com, Jonathan Corbet , Joonsoo Kim , Kees Cook , Mark Rutland , Pekka Enberg , Peter Zijlstra , sjpark@amazon.com, Thomas Gleixner , Vlastimil Babka , Will Deacon , "the arch/x86 maintainers" , linux-doc@vger.kernel.org, kernel list , kasan-dev , Linux ARM , Linux-MM , SeongJae Park Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 2, 2020 at 8:33 AM Jann Horn wrote: > On Tue, Sep 29, 2020 at 3:38 PM Marco Elver wrote: > > 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. [...] > > +/* > > + * The pool of pages used for guard pages and objects. If supported, allocated > > + * statically, so that is_kfence_address() avoids a pointer load, and simply > > + * compares against a constant address. Assume that if KFENCE is compiled into > > + * the kernel, it is usually enabled, and the space is to be allocated one way > > + * or another. > > + */ > > If this actually brings a performance win, the proper way to do this > would probably be to implement this as generic kernel infrastructure > that makes the compiler emit large-offset relocations (either through > compiler support or using inline asm statements that move an immediate > into a register output and register the location in a special section, > kinda like how e.g. static keys work) and patches them at boot time, > or something like that - there are other places in the kernel where > very hot code uses global pointers that are only ever written once > during boot, e.g. the dentry cache of the VFS and the futex hash > table. Those are probably far hotter than the kfence code. > > While I understand that that goes beyond the scope of this project, it > might be something to work on going forward - this kind of > special-case logic that turns the kernel data section into heap memory > would not be needed if we had that kind of infrastructure. After thinking about it a bit more, I'm not even convinced that this is a net positive in terms of overall performance - while it allows you to avoid one level of indirection in some parts of kfence, that kfence code by design only runs pretty infrequently. And to enable this indirection avoidance, your x86 arch_kfence_initialize_pool() is shattering potentially unrelated hugepages in the kernel data section, which might increase the TLB pressure (and therefore the number of memory loads that have to fall back to slow page walks) in code that is much hotter than yours. And if this indirection is a real performance problem, that problem would be many times worse in the VFS and the futex subsystem, so developing a more generic framework for doing this cleanly would be far more important than designing special-case code to allow kfence to do this. And from what I've seen, a non-trivial chunk of the code in this series, especially the arch/ parts, is only necessary to enable this microoptimization. Do you have performance numbers or a description of why you believe that this part of kfence is exceptionally performance-sensitive? If not, it might be a good idea to remove this optimization, at least for the initial version of this code. (And even if the optimization is worthwhile, it might be a better idea to go for the generic version immediately.) 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,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 BABF1C4727F for ; Fri, 2 Oct 2020 07:54:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3379820719 for ; Fri, 2 Oct 2020 07:54:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ZImYzlgj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3379820719 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 6EF038E0001; Fri, 2 Oct 2020 03:54:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 69F1D6B006E; Fri, 2 Oct 2020 03:54:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B4F78E0001; Fri, 2 Oct 2020 03:54:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0140.hostedemail.com [216.40.44.140]) by kanga.kvack.org (Postfix) with ESMTP id 319F56B005D for ; Fri, 2 Oct 2020 03:54:04 -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 C04EC8249980 for ; Fri, 2 Oct 2020 07:54:03 +0000 (UTC) X-FDA: 77326221966.23.copy30_4f0ac64271a2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 9C80837606 for ; Fri, 2 Oct 2020 07:54:03 +0000 (UTC) X-HE-Tag: copy30_4f0ac64271a2 X-Filterd-Recvd-Size: 7584 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Fri, 2 Oct 2020 07:54:02 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id t16so700546edw.7 for ; Fri, 02 Oct 2020 00:54:02 -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=e6vV2mQW9X/bc3rvl043TXcmZeVV1Y9QdMUbU/DoAeE=; b=ZImYzlgjXsFUc2CCMT9j97ZUOzil+3t99KxFvX4NmLd7QCKth6NtxJkTizVZrbxLJl XuvPQrG5tlvHtzGj+IlQKy5HBgv5uBemIZU053zhGAVXxs2OXDmzcmv7i1ITAS9v7aax HfJzfaD+0Uz9InQ58lwv3LPQblvNPk0i+iIhujWGXNEhWqaDtFuS8Zpc+hkUOCx7E9xi WF0YlRjZrwO+Y/k728n8WDQqJ3TnLJJISWx8k2HM9urYCqKo0eZ02BDG/XfaH2eIEA6W nQPGal9DyIq+497MJY0Pfaf3Rge5lwVUdXx+8GDCqnhvOg82rS7CxbgH7Tg5SWvEyt3R iT0g== 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=e6vV2mQW9X/bc3rvl043TXcmZeVV1Y9QdMUbU/DoAeE=; b=YHhmD6GPsp1gaabqSY6DcvoKps0JkpzAcl0kRFF+eUxLUjcoe2GYlVqhmZoFZkAvwG P50AM95dhkoWwRHRVABkolJlXiP2M41mulk3eCua6kfldd2Cs3ZBWB7pDr77pe85kpPP Pxmj/ab10elQ3Bphte5niiUy3VtpIk1NCimTZ+J9OAOkqlOw5umma9SOf9HoO+vrUI8L OEs2mihocksUz+yA+cYrC7D3CrI0FjgxzxpJSH1la8Hadn5qcLutM99+SIvTsG/SFi6n 9vOOIq1JN5zlryVaYZr6XQixK576O/GAEZXdU83qUb270lViviAsRA+lSyNgUZyGFGyO FO+A== X-Gm-Message-State: AOAM530FbNGpWBIpKvsVnPcmbLUOVPFObgSe/sDNahS0vZGXz6JheJGk mdqyuQjiY6LUJP8WZuK4bWR860GuXJzB1TjWbTVKMw== X-Google-Smtp-Source: ABdhPJw8JCv+/xESYG7KtHUsTPSjS1wwtCM31dmLgZK5YLiFsgcQliR929HzUjpB/jwncke9ycuFEY9U+TB0Bt5y718= X-Received: by 2002:a05:6402:b0e:: with SMTP id bm14mr1055829edb.259.1601625241408; Fri, 02 Oct 2020 00:54:01 -0700 (PDT) MIME-Version: 1.0 References: <20200929133814.2834621-1-elver@google.com> <20200929133814.2834621-2-elver@google.com> In-Reply-To: From: Jann Horn Date: Fri, 2 Oct 2020 09:53:34 +0200 Message-ID: Subject: Re: [PATCH v4 01/11] mm: add Kernel Electric-Fence infrastructure To: Marco Elver Cc: Andrew Morton , Alexander Potapenko , "H . Peter Anvin" , "Paul E . McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christoph Lameter , Dave Hansen , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jonathan.Cameron@huawei.com, Jonathan Corbet , Joonsoo Kim , Kees Cook , Mark Rutland , Pekka Enberg , Peter Zijlstra , sjpark@amazon.com, Thomas Gleixner , Vlastimil Babka , Will Deacon , "the arch/x86 maintainers" , linux-doc@vger.kernel.org, kernel list , kasan-dev , Linux ARM , Linux-MM , SeongJae Park 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 Fri, Oct 2, 2020 at 8:33 AM Jann Horn wrote: > On Tue, Sep 29, 2020 at 3:38 PM Marco Elver wrote: > > 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. [...] > > +/* > > + * The pool of pages used for guard pages and objects. If supported, allocated > > + * statically, so that is_kfence_address() avoids a pointer load, and simply > > + * compares against a constant address. Assume that if KFENCE is compiled into > > + * the kernel, it is usually enabled, and the space is to be allocated one way > > + * or another. > > + */ > > If this actually brings a performance win, the proper way to do this > would probably be to implement this as generic kernel infrastructure > that makes the compiler emit large-offset relocations (either through > compiler support or using inline asm statements that move an immediate > into a register output and register the location in a special section, > kinda like how e.g. static keys work) and patches them at boot time, > or something like that - there are other places in the kernel where > very hot code uses global pointers that are only ever written once > during boot, e.g. the dentry cache of the VFS and the futex hash > table. Those are probably far hotter than the kfence code. > > While I understand that that goes beyond the scope of this project, it > might be something to work on going forward - this kind of > special-case logic that turns the kernel data section into heap memory > would not be needed if we had that kind of infrastructure. After thinking about it a bit more, I'm not even convinced that this is a net positive in terms of overall performance - while it allows you to avoid one level of indirection in some parts of kfence, that kfence code by design only runs pretty infrequently. And to enable this indirection avoidance, your x86 arch_kfence_initialize_pool() is shattering potentially unrelated hugepages in the kernel data section, which might increase the TLB pressure (and therefore the number of memory loads that have to fall back to slow page walks) in code that is much hotter than yours. And if this indirection is a real performance problem, that problem would be many times worse in the VFS and the futex subsystem, so developing a more generic framework for doing this cleanly would be far more important than designing special-case code to allow kfence to do this. And from what I've seen, a non-trivial chunk of the code in this series, especially the arch/ parts, is only necessary to enable this microoptimization. Do you have performance numbers or a description of why you believe that this part of kfence is exceptionally performance-sensitive? If not, it might be a good idea to remove this optimization, at least for the initial version of this code. (And even if the optimization is worthwhile, it might be a better idea to go for the generic version immediately.) 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=-3.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 4E3C9C4363D for ; Fri, 2 Oct 2020 07:55:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D15D920672 for ; Fri, 2 Oct 2020 07:55:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="TEwVX0k/"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="ZImYzlgj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D15D920672 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=RHt9y98QQAkTBfsSAofy4ZfD1Fy52UrBg5uhXL8iDLE=; b=TEwVX0k/+zFmxpp1jrIv+voTF DCYrGRYfCGy4RLUkKd0CI/gH3i/VBqJKNVAELAVyYHs2Nue0P0Dm9syCRCVox+G9OmpLhbjYUuRp4 q1fNJdoMxJdZkw67J9dY9+nLY+gt/7GT/V7WMAoiLYLd8M6M77aQ84GseUUqrB/IxXtlc+eShstTu H9jdbwEHgpf4PPQUbuAg44LMqEeSyjKVeqIHiN5rMJzpag97YnSPKuDJEHSw0ZsTjo7dRJAZpE0RF KTre81MeeFZy8wMU4qEWM51kpEUhtVdAVkwpp5G0HfJXljCLE2INdtZsRptQq1B24gYBakHishCfz +7ifnerJw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kOFtF-0002ab-9v; Fri, 02 Oct 2020 07:54:05 +0000 Received: from mail-ed1-x542.google.com ([2a00:1450:4864:20::542]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kOFtC-0002Zq-Ok for linux-arm-kernel@lists.infradead.org; Fri, 02 Oct 2020 07:54:03 +0000 Received: by mail-ed1-x542.google.com with SMTP id dn5so693119edb.10 for ; Fri, 02 Oct 2020 00:54:02 -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=e6vV2mQW9X/bc3rvl043TXcmZeVV1Y9QdMUbU/DoAeE=; b=ZImYzlgjXsFUc2CCMT9j97ZUOzil+3t99KxFvX4NmLd7QCKth6NtxJkTizVZrbxLJl XuvPQrG5tlvHtzGj+IlQKy5HBgv5uBemIZU053zhGAVXxs2OXDmzcmv7i1ITAS9v7aax HfJzfaD+0Uz9InQ58lwv3LPQblvNPk0i+iIhujWGXNEhWqaDtFuS8Zpc+hkUOCx7E9xi WF0YlRjZrwO+Y/k728n8WDQqJ3TnLJJISWx8k2HM9urYCqKo0eZ02BDG/XfaH2eIEA6W nQPGal9DyIq+497MJY0Pfaf3Rge5lwVUdXx+8GDCqnhvOg82rS7CxbgH7Tg5SWvEyt3R iT0g== 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=e6vV2mQW9X/bc3rvl043TXcmZeVV1Y9QdMUbU/DoAeE=; b=SZmMODhbVmYhcRf3q+hGS3F5hMGxrHDubjAGpNT4LObiKhzsftni6LaaErkkpDu7bg e++nxZVaIYxVzqGiIo42+rq06fxVfQxHSgtwsGHzTbDNnnI9i6Qp5xzHs4SM5n1KK6jx 187309mCfBf5CeCWwt06vM24FV7ugbgLAXvMV+bwGyurzlCHTRBO3oH/noicoPEoVCu6 p5pfNqlre1WpR1Bmt6qRbzRJc05v9fhWCbn/XSbyLXJCKMNkPH8uu2qxqKIlFdYeW0U7 kC3fL/czvcJpUY1Cdp+KW6rLH7KbUgVCRsqPXA8EAbj968Ne4C5vGkRlSrf2uqlh64E2 K6oA== X-Gm-Message-State: AOAM530cwsxWZDjHEkH3MP6jWtr9+5diTJdKkxXJ/CJcb2kD7EZhrUHP KDxYjNEqm4GHeCUE5c9Mr7vSJRcGkUUOpVig2OY4ig== X-Google-Smtp-Source: ABdhPJw8JCv+/xESYG7KtHUsTPSjS1wwtCM31dmLgZK5YLiFsgcQliR929HzUjpB/jwncke9ycuFEY9U+TB0Bt5y718= X-Received: by 2002:a05:6402:b0e:: with SMTP id bm14mr1055829edb.259.1601625241408; Fri, 02 Oct 2020 00:54:01 -0700 (PDT) MIME-Version: 1.0 References: <20200929133814.2834621-1-elver@google.com> <20200929133814.2834621-2-elver@google.com> In-Reply-To: From: Jann Horn Date: Fri, 2 Oct 2020 09:53:34 +0200 Message-ID: Subject: Re: [PATCH v4 01/11] mm: add Kernel Electric-Fence infrastructure To: Marco Elver X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201002_035402_875850_115FF68F X-CRM114-Status: GOOD ( 29.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Hillf Danton , linux-doc@vger.kernel.org, Peter Zijlstra , Catalin Marinas , Dave Hansen , SeongJae Park , Linux-MM , Eric Dumazet , Alexander Potapenko , "H . Peter Anvin" , Christoph Lameter , Will Deacon , sjpark@amazon.com, Jonathan Corbet , the arch/x86 maintainers , kasan-dev , Ingo Molnar , Vlastimil Babka , David Rientjes , Andrey Ryabinin , Kees Cook , "Paul E . McKenney" , Andrey Konovalov , Borislav Petkov , Andy Lutomirski , Jonathan.Cameron@huawei.com, Thomas Gleixner , Andrew Morton , Dmitry Vyukov , Linux ARM , Greg Kroah-Hartman , kernel list , Pekka Enberg , Joonsoo Kim Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 2, 2020 at 8:33 AM Jann Horn wrote: > On Tue, Sep 29, 2020 at 3:38 PM Marco Elver wrote: > > 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. [...] > > +/* > > + * The pool of pages used for guard pages and objects. If supported, allocated > > + * statically, so that is_kfence_address() avoids a pointer load, and simply > > + * compares against a constant address. Assume that if KFENCE is compiled into > > + * the kernel, it is usually enabled, and the space is to be allocated one way > > + * or another. > > + */ > > If this actually brings a performance win, the proper way to do this > would probably be to implement this as generic kernel infrastructure > that makes the compiler emit large-offset relocations (either through > compiler support or using inline asm statements that move an immediate > into a register output and register the location in a special section, > kinda like how e.g. static keys work) and patches them at boot time, > or something like that - there are other places in the kernel where > very hot code uses global pointers that are only ever written once > during boot, e.g. the dentry cache of the VFS and the futex hash > table. Those are probably far hotter than the kfence code. > > While I understand that that goes beyond the scope of this project, it > might be something to work on going forward - this kind of > special-case logic that turns the kernel data section into heap memory > would not be needed if we had that kind of infrastructure. After thinking about it a bit more, I'm not even convinced that this is a net positive in terms of overall performance - while it allows you to avoid one level of indirection in some parts of kfence, that kfence code by design only runs pretty infrequently. And to enable this indirection avoidance, your x86 arch_kfence_initialize_pool() is shattering potentially unrelated hugepages in the kernel data section, which might increase the TLB pressure (and therefore the number of memory loads that have to fall back to slow page walks) in code that is much hotter than yours. And if this indirection is a real performance problem, that problem would be many times worse in the VFS and the futex subsystem, so developing a more generic framework for doing this cleanly would be far more important than designing special-case code to allow kfence to do this. And from what I've seen, a non-trivial chunk of the code in this series, especially the arch/ parts, is only necessary to enable this microoptimization. Do you have performance numbers or a description of why you believe that this part of kfence is exceptionally performance-sensitive? If not, it might be a good idea to remove this optimization, at least for the initial version of this code. (And even if the optimization is worthwhile, it might be a better idea to go for the generic version immediately.) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel