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.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 A4321C4727D for ; Fri, 2 Oct 2020 15:07:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 29B7C2074B for ; Fri, 2 Oct 2020 15:06:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29B7C2074B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5FDAF6B005C; Fri, 2 Oct 2020 11:06:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 585FC6B005D; Fri, 2 Oct 2020 11:06:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 426236B0062; Fri, 2 Oct 2020 11:06:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0228.hostedemail.com [216.40.44.228]) by kanga.kvack.org (Postfix) with ESMTP id 0CBA76B005C for ; Fri, 2 Oct 2020 11:06:59 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 92D55362A for ; Fri, 2 Oct 2020 15:06:58 +0000 (UTC) X-FDA: 77327312916.22.sense01_600515a271a5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 64DB818038E68 for ; Fri, 2 Oct 2020 15:06:58 +0000 (UTC) X-HE-Tag: sense01_600515a271a5 X-Filterd-Recvd-Size: 5587 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Fri, 2 Oct 2020 15:06:57 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B12B41396; Fri, 2 Oct 2020 08:06:56 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.49.154]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 45F5C3F73B; Fri, 2 Oct 2020 08:06:50 -0700 (PDT) Date: Fri, 2 Oct 2020 16:06:43 +0100 From: Mark Rutland To: Dmitry Vyukov Cc: Jann Horn , Marco Elver , 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 , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jonathan.Cameron@huawei.com, Jonathan Corbet , Joonsoo Kim , Kees Cook , Pekka Enberg , Peter Zijlstra , sjpark@amazon.com, Thomas Gleixner , Vlastimil Babka , Will Deacon , the arch/x86 maintainers , "open list:DOCUMENTATION" , kernel list , kasan-dev , Linux ARM , Linux-MM , SeongJae Park Subject: Re: [PATCH v4 01/11] mm: add Kernel Electric-Fence infrastructure Message-ID: <20201002150643.GA5601@C02TD0UTHF1T.local> References: <20200929133814.2834621-1-elver@google.com> <20200929133814.2834621-2-elver@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 02, 2020 at 04:22:59PM +0200, Dmitry Vyukov wrote: > On Fri, Oct 2, 2020 at 9:54 AM Jann Horn wrote: > > > > 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. > > > > + */ > KFENCE needs the range to be covered by struct page's and that's what > creates problems for arm64. But I would assume most other users don't > need that. I've said this in a few other sub-threads, but the issue being attributed to arm64 is a red herring, and indicates a more fundamental issue that also applies to x86, which will introduce a regression for existing correctly-written code. I don't think that's acceptable for a feature expected to be deployed in production kernels, especially given that the failures are going to be non-deterministic and hard to debug. The code in question is mostly going to be in drivers, and it's very likely you may not hit it in local testing. If it is critical to avoid a pointer load here, then we need to either: * Build some infrastructure for patching constants. The x86 static_call work is vaguely the right shape for this. Then we can place the KFENCE region anywhere (e.g. within the linear/direct map), and potentially dynamically allocate it. * Go audit usage of {page,phys}_to_virt() to find any va->{page,pa}->va round-trips, and go modify that code to do something else which avoids a round-trip. When I last looked at this it didn't seem viable in general since in many cases the physcial address was the only piece of information which was retained. I'd be really curious to see how using an immediate compares to loading an __ro_after_init pointer value. Thanks, Mark.