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 2D801C4363A for ; Fri, 30 Oct 2020 02:50:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9EE4D207DE for ; Fri, 30 Oct 2020 02:50:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="iW5ihpg+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9EE4D207DE 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 250F86B005D; Thu, 29 Oct 2020 22:50:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D9936B006C; Thu, 29 Oct 2020 22:50:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A2226B0083; Thu, 29 Oct 2020 22:50:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0194.hostedemail.com [216.40.44.194]) by kanga.kvack.org (Postfix) with ESMTP id CDD5F6B005D for ; Thu, 29 Oct 2020 22:50:22 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6D1A13623 for ; Fri, 30 Oct 2020 02:50:22 +0000 (UTC) X-FDA: 77427063084.17.feast84_1f0923427292 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 52A72180D0181 for ; Fri, 30 Oct 2020 02:50:22 +0000 (UTC) X-HE-Tag: feast84_1f0923427292 X-Filterd-Recvd-Size: 6886 Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Fri, 30 Oct 2020 02:50:21 +0000 (UTC) Received: by mail-lj1-f195.google.com with SMTP id y16so5388269ljk.1 for ; Thu, 29 Oct 2020 19:50:21 -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=eoeNB3Dm2STEtOexs69p6fZG9+pIZ5Rd4jeKPI0aVt4=; b=iW5ihpg+JZ2/yUGtXbJNyGMMZriSOPNnlB3GV0zM6Mtiktse/EwhBGbcQZZZH+ocfG NIT3WX1VqpVPxzoCFCmcm/hhAjRxrvU8gEV93fe18PhNgE9efkKNdPSP8gfmcdtWBm1N OQ7Z0YYCFk04/U1vmuBGnc+qG8/Xvq/lsaJisf8R/NdH5ptqdSzdU7GtM5g0B/XxZDGA T6jCTxwdy4DPM0lyH2V7LTXTzDAkoXeOz8/h6SQSRRkYvUoQI9+aWZPlx3ktWrQWzZKI kpcS4PF3e5vY/XCoaUzT2Pkgy/aTXlK2UX9nqYk1u+GlsEirxu4Ku5nYzo9Cd4kuqBpi ESfg== 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=eoeNB3Dm2STEtOexs69p6fZG9+pIZ5Rd4jeKPI0aVt4=; b=IJ2Rtq62Z32/YfOaNyQjV9Othgkc/AN9Dur3SSs4lo9tti6S49uMiZZ8CefCwnYnAa IxJ+fqH2rcZiUz7nprq2N0xTps4YEv4Ms8vrlw2gh1EuIM40POulzGPBkEeQIRlk0T7t 2weozZRSd/KnrFGs9n3/Ar42NrtD6Pgi8vcElO+Ged0uU9aQknHf4PKfy/fDXhN0UJ99 I9xMlVn4+K31HA9ZLx2o2RH7eCMwycrYtxlxjbqD1zt7OetjFXoSXzlKO2eDjlrTICAe eLcLivJ4jmRBolVZPNE8KkePQgILStmHpjemOjL2+oznotAodMNm2aQDpFCkiOFom/i5 zuqQ== X-Gm-Message-State: AOAM530Fs8YdpidvlHA9JFIsB2OykszjlCI3CAmJ3/P1Jt0AvMIJcd8A JLj8E7ZMxpCAM4TRWgqiadz5Sw4nUcjLouMTzKvXYw== X-Google-Smtp-Source: ABdhPJzeE3oggLRKXmuhnJNQcjEqRcQBQF55b9TKu2lm5R+dh/rb0VPrh3CNfN76ySyQwy3jzXL4HMhNES1XqkD5gAQ= X-Received: by 2002:a2e:b888:: with SMTP id r8mr99590ljp.138.1604026220407; Thu, 29 Oct 2020 19:50:20 -0700 (PDT) MIME-Version: 1.0 References: <20201029131649.182037-1-elver@google.com> <20201029131649.182037-8-elver@google.com> In-Reply-To: <20201029131649.182037-8-elver@google.com> From: Jann Horn Date: Fri, 30 Oct 2020 03:49:53 +0100 Message-ID: Subject: Re: [PATCH v6 7/9] kfence, Documentation: add KFENCE documentation 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 , Jonathan Corbet , Joonsoo Kim , joern@purestorage.com, Kees Cook , Mark Rutland , Pekka Enberg , Peter Zijlstra , SeongJae Park , Thomas Gleixner , Vlastimil Babka , Will Deacon , "the arch/x86 maintainers" , "open list:DOCUMENTATION" , kernel list , kasan-dev , Linux ARM , Linux-MM 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 Thu, Oct 29, 2020 at 2:17 PM Marco Elver wrote: > Add KFENCE documentation in dev-tools/kfence.rst, and add to index. [...] > +The KFENCE memory pool is of fixed size, and if the pool is exhausted, no > +further KFENCE allocations occur. With ``CONFIG_KFENCE_NUM_OBJECTS`` (default > +255), the number of available guarded objects can be controlled. Each object > +requires 2 pages, one for the object itself and the other one used as a guard > +page; object pages are interleaved with guard pages, and every object page is > +therefore surrounded by two guard pages. > + > +The total memory dedicated to the KFENCE memory pool can be computed as:: > + > + ( #objects + 1 ) * 2 * PAGE_SIZE Plus memory overhead from shattered hugepages. With the default object count, on x86, we allocate 2MiB of memory pool, but if we have to shatter a 2MiB hugepage for that, we may cause the allocation of one extra page table, or 4KiB. Of course that's pretty much negligible. But on arm64 it's worse, because there we have to disable hugepages in the linear map completely. So on a device with 4GiB memory, we might end up with something on the order of 4GiB/2MiB * 0x1000 bytes = 8MiB of extra L1 page tables that wouldn't have been needed otherwise - significantly more than the default memory pool size. If the memory overhead is documented, this detail should probably be documented, too. > +Using the default config, and assuming a page size of 4 KiB, results in > +dedicating 2 MiB to the KFENCE memory pool. [...] > +For such errors, the address where the corruption as well as the invalidly nit: "the address where the corruption occurred" or "the address of the corruption" > +written bytes (offset from the address) are shown; in this representation, '.' > +denote untouched bytes. In the example above ``0xac`` is the value written to > +the invalid address at offset 0, and the remaining '.' denote that no following > +bytes have been touched. Note that, real values are only shown for > +``CONFIG_DEBUG_KERNEL=y`` builds; to avoid information disclosure for non-debug > +builds, '!' is used instead to denote invalidly written bytes. [...] > +KFENCE objects each reside on a dedicated page, at either the left or right > +page boundaries selected at random. 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. Such page faults are then > +intercepted by KFENCE, which handles the fault gracefully by reporting an > +out-of-bounds access. ... and marking the page as accessible so that the faulting code can continue (wrongly) executing. [...] > +Interface > +--------- > + > +The following describes the functions which are used by allocators as well page nit: "as well as"? > +handling code to set up and deal with KFENCE allocations.