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 6D9F5C4741F for ; Tue, 29 Sep 2020 13:54:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2504420848 for ; Tue, 29 Sep 2020 13:54:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729557AbgI2NyN (ORCPT ); Tue, 29 Sep 2020 09:54:13 -0400 Received: from foss.arm.com ([217.140.110.172]:45118 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728487AbgI2NyM (ORCPT ); Tue, 29 Sep 2020 09:54:12 -0400 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 4BCA931B; Tue, 29 Sep 2020 06:54:11 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.51.69]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 055C73F6CF; Tue, 29 Sep 2020 06:54:03 -0700 (PDT) Date: Tue, 29 Sep 2020 14:53:55 +0100 From: Mark Rutland To: Marco Elver Cc: Will Deacon , Alexander Potapenko , Andrew Morton , "H. Peter Anvin" , "Paul E. McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christoph Lameter , Dave Hansen , David Rientjes , Dmitriy Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jann Horn , Jonathan Cameron , Jonathan Corbet , Joonsoo Kim , Kees Cook , Pekka Enberg , Peter Zijlstra , SeongJae Park , Thomas Gleixner , Vlastimil Babka , the arch/x86 maintainers , "open list:DOCUMENTATION" , LKML , kasan-dev , Linux ARM , Linux Memory Management List Subject: Re: [PATCH v3 03/10] arm64, kfence: enable KFENCE for ARM64 Message-ID: <20200929135355.GA53442@C02TD0UTHF1T.local> References: <20200921132611.1700350-1-elver@google.com> <20200921132611.1700350-4-elver@google.com> <20200921143059.GO2139@willie-the-truck> <20200921174357.GB3141@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Tue, Sep 22, 2020 at 11:56:26AM +0200, Marco Elver wrote: > On Mon, 21 Sep 2020 at 19:44, Will Deacon wrote: > [...] > > > > > > For ARM64, we would like to solicit feedback on what the best option is > > > > > > to obtain a constant address for __kfence_pool. One option is to declare > > > > > > a memory range in the memory layout to be dedicated to KFENCE (like is > > > > > > done for KASAN), however, it is unclear if this is the best available > > > > > > option. We would like to avoid touching the memory layout. > > > > > > > > > > Sorry for the delay on this. > > > > > > > > NP, thanks for looking! > > > > > > > > > Given that the pool is relatively small (i.e. when compared with our virtual > > > > > address space), dedicating an area of virtual space sounds like it makes > > > > > the most sense here. How early do you need it to be available? > > > > > > > > Yes, having a dedicated address sounds good. > > > > We're inserting kfence_init() into start_kernel() after timekeeping_init(). > > > > So way after mm_init(), if that matters. > > > > > > The question is though, how big should that dedicated area be? > > > Right now KFENCE_NUM_OBJECTS can be up to 16383 (which makes the pool > > > size 64MB), but this number actually comes from the limitation on > > > static objects, so we might want to increase that number on arm64. > > > > What happens on x86 and why would we do something different? > > On x86 we just do `char __kfence_pool[KFENCE_POOL_SIZE] ...;` to > statically allocate the pool. On arm64 this doesn't seem to work > because static memory doesn't have struct pages? Are you using virt_to_page() directly on that statically-allocated __kfence_pool? If so you'll need to use lm_alias() if so, as is done in mm/kasan/init.c. Anything statically allocated is part of the kernel image address range rather than the linear/direct map, and doesn't have a valid virt addr, but its linear map alias does. If you enable CONFIG_DEBUG_VIRTUAL you should get warnings if missing lm_alias() calls. Thanks, Mark.