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=-14.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,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 53FFCC43465 for ; Mon, 21 Sep 2020 15:37:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DD3AC20B1F for ; Mon, 21 Sep 2020 15:37:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="BYc74rVc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DD3AC20B1F 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 7778E6B00ED; Mon, 21 Sep 2020 11:37:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74CF56B00EE; Mon, 21 Sep 2020 11:37:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 662EC6B00EF; Mon, 21 Sep 2020 11:37:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0245.hostedemail.com [216.40.44.245]) by kanga.kvack.org (Postfix) with ESMTP id 505F16B00ED for ; Mon, 21 Sep 2020 11:37:24 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1123B8249980 for ; Mon, 21 Sep 2020 15:37:24 +0000 (UTC) X-FDA: 77287472808.13.drink72_4502aef27146 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id E41B718140B60 for ; Mon, 21 Sep 2020 15:37:23 +0000 (UTC) X-HE-Tag: drink72_4502aef27146 X-Filterd-Recvd-Size: 5970 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 15:37:23 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id b79so13206521wmb.4 for ; Mon, 21 Sep 2020 08:37:23 -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=kVxfXE34UyHx4a9aedDaVHUi6pKMiF4098HvY7EGT4c=; b=BYc74rVcObsxY5RoY7FBMvjUz7I+HJaB7IhAMx9FrV1rganW2S1g6KUoFgpgpnqRys SMWPacFyEdfqMPAw5HLCbJQmqVoKTUYfmyOBS5OBxGnpGhFWTsvJUDm8nnbfIdQAnRtP aWeprctyWDcO0WTV0CPMaJuFaew74ic3MENre4wcGr/Tr9AA0Es0vAnGTQmPqQQH9S+o +AkdKBo++MoypREVKrTr/WFM2sS3+L4CeJ6HVm2xZY0709ol4d7QVZZEDV8tRX6B77wj ZTn0MrnZ2DI7QIXulRGzqTFj1m6iSSKzHv/qCHZXxt2ZHklgUOXHUQGCBfgHNiYtlCCe vWHw== 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=kVxfXE34UyHx4a9aedDaVHUi6pKMiF4098HvY7EGT4c=; b=n12C0PGSrQStykk9o8ibL/zHiOd9XvtGXJx8YGbEwr0Mbauxel5IEi8TotatA0GwKS BTVVW44jYHM4jw5TRNqBJxbY53feYlSEeuRO++0yHhhSn0fpqDA/p8uJeO6J79FAUbb3 Ok5AtKQPE6UD0Ec1ksR+sA7y1sxB9A1xZ6I/bJo8eMYqnKYmceqQnc/mgkpXGfQrLA/A BWTvW+itD1d8UZ7CNRWOqAhLEoGNr0UN40FbDqPfTTkZ6Y6TBJOrR+DDCxLrssYUFDPs W+zrSQtEopvU1lOuWXMYBucyL115gHA6yK74L5ehjiYanpj2avJH/84rPHN+ddKwcb1z 6tcA== X-Gm-Message-State: AOAM530hD2oU+zUmzAEFEWWEtZaCyM9l8P8iV2NdbFTxRDjRbBT1Cnd+ xBWKbfJMrkRXkVRrklhTQOrBnfo3LM7xeL2KH8UCpA== X-Google-Smtp-Source: ABdhPJxOztNZkizJnsXhj3wk+nWXFKqGPJsuyIzMb4d7s9SxqbYZ2lfULvl21tc0mzpAWLEjISHQ1AcbURiGb5k8xgg= X-Received: by 2002:a7b:c4d3:: with SMTP id g19mr199189wmk.165.1600702641972; Mon, 21 Sep 2020 08:37:21 -0700 (PDT) MIME-Version: 1.0 References: <20200921132611.1700350-1-elver@google.com> <20200921132611.1700350-4-elver@google.com> <20200921143059.GO2139@willie-the-truck> In-Reply-To: From: Alexander Potapenko Date: Mon, 21 Sep 2020 17:37:10 +0200 Message-ID: Subject: Re: [PATCH v3 03/10] arm64, kfence: enable KFENCE for ARM64 To: Will Deacon Cc: Marco Elver , 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@huawei.com, Jonathan Corbet , Joonsoo Kim , Kees Cook , Mark Rutland , Pekka Enberg , Peter Zijlstra , sjpark@amazon.com, Thomas Gleixner , Vlastimil Babka , "the arch/x86 maintainers" , "open list:DOCUMENTATION" , LKML , kasan-dev , Linux ARM , Linux Memory Management List 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 Mon, Sep 21, 2020 at 4:58 PM Alexander Potapenko wrote: > > On Mon, Sep 21, 2020 at 4:31 PM Will Deacon wrote: > > > > On Mon, Sep 21, 2020 at 03:26:04PM +0200, Marco Elver wrote: > > > Add architecture specific implementation details for KFENCE and enable > > > KFENCE for the arm64 architecture. In particular, this implements the > > > required interface in . Currently, the arm64 version does > > > not yet use a statically allocated memory pool, at the cost of a pointer > > > load for each is_kfence_address(). > > > > > > Reviewed-by: Dmitry Vyukov > > > Co-developed-by: Alexander Potapenko > > > Signed-off-by: Alexander Potapenko > > > Signed-off-by: Marco Elver > > > --- > > > 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.