Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3211440pxk; Mon, 21 Sep 2020 08:00:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz0F5I7dlct71hm/NDE3Zdvl105Jf3RheTAY8MLQb/9HBhJ0OYhq5N9VfV8neM74V0xU3aZ X-Received: by 2002:aa7:da0f:: with SMTP id r15mr9153eds.321.1600700419337; Mon, 21 Sep 2020 08:00:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600700419; cv=none; d=google.com; s=arc-20160816; b=yRc8M7iW4hGUP0urdayyCsHa++AA3vzROlELNNWwNKSa6qD83DUVq4TRAyKw/LaW1I A9/lEsahHkFlpKw8IjZjpsI29cy7zVijgFknA3acDDt3kb92fo2f4Y4nsYAadI+60N7z OSeMVn95HqpRXZf6eA9ljOAvY7+x+NK4aLMmEWISi8z4GMCI9XYkgr1gffDdxhFMUas1 tiseKuvuZsmdvi7lTOhDEMYqOO816PXZLuBbHJbb/uoIcl/EhWNB20IWCyYKjb04PmG9 nQK9j6ImZG3gJstaMmadSdF+AAHa2IQQ4v9xdZWBPrSmLeZDwb701PpKn60cxLUo0870 XIKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=J02fUfHHsGOzjhQyl/tGfPUtfr9BJPAQxULq+u6ZRXM=; b=i3ORFFhTwfAV8aP39VHyaettyQw1g94RwsQMryF2D41MH0NjCdq3xALGgi1v2xIAO+ 7QGdXqeOjobv9RYCo36aTU/cirmcY0MNqp7VT/cR+kWUsCMBrjxm50B1PKtYr6w7VogG 3+FWkEuP3KB2+YAgvYKuRhVq2nBl2d2+IlgjD2+MyG86LYqOUAnEO2/gLda/1pVkxAGY /u2BL42Rd0cfpgyKvAHAVCNNm0hZ6jK81AMnNgv5xn7Zopmfv0yZn/qpozRq9552lh2V 1bUDWdwDExbuTaLN5uU3RVcoEzss1KS7pGuEDxidqcFIpvURamrjw7Kdyq+/JkIOsZ8t tLiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=pihm+3yZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r16si8094225edt.192.2020.09.21.07.59.55; Mon, 21 Sep 2020 08:00:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=pihm+3yZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727745AbgIUO6a (ORCPT + 99 others); Mon, 21 Sep 2020 10:58:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45974 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726471AbgIUO63 (ORCPT ); Mon, 21 Sep 2020 10:58:29 -0400 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C689C061755 for ; Mon, 21 Sep 2020 07:58:29 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id k18so13059527wmj.5 for ; Mon, 21 Sep 2020 07:58:29 -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:content-transfer-encoding; bh=J02fUfHHsGOzjhQyl/tGfPUtfr9BJPAQxULq+u6ZRXM=; b=pihm+3yZMKHKcYdASAww1rGEr2Dxntu4UArY54j2rSj/+nD8st9ACxliUmFGSoTDpl SYW62IX43tVBiVLsps+pLlr7PiVubwfDVu+sMPAAohuq9lp51Wt+ZKPdFLEW5q1jOV8c gHEiTzelfZRUecETp856lFG5KxFqbnWRRKGCMMVYJZjouqjBSXhYGnFaCZFWXgSa1LUb ai9mNZxna9283GvRyEzueoFeoB+ZRgjB5RX5cuh1j9wmW0tjAud9Zcy8sSSNEi8Xb2ng Z3Tf5sz8f37TbIMVt9ldV5IFpSNNDZPcFzAk2iQT9uFSoB6+wMOCyrSDB5nuhmuIbtdW L2rw== 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:content-transfer-encoding; bh=J02fUfHHsGOzjhQyl/tGfPUtfr9BJPAQxULq+u6ZRXM=; b=mTy04MzauDrkeDSh0l0hrNGlEkgKG9Z1D8u1vciF/ppg39ed8vPsbcnJG/3ZCX+Ulc 7qRd9dFG7XbTXuw7aTzkoQLEFDFIFzcn8lIvx5k5wH/Fb41dFjHlTFTjLqEMY2lPPyU8 M0x6SR+FZCJ6BB42OrX1wE7+iiR6brMqgjVx/eoQKwj4y38f1CPdkUv/EKGFIZHarzvz A3Lw/RdOhRkJRbLjJvxxj9sGdbZ3g8Rk6G47RkMXULrvQ487s0h4pmDc4O0aUM7pQuuy +dNyghNxazWXhOl3JcwHrQHsd+xkytQYo0f4Hb+ZUkvYuEKh4ZRtBC4BMbP9rMnBekx9 FGXw== X-Gm-Message-State: AOAM532/zJ/CSbP912gpxFX2tB2KBb3CXOm8hbcxLg5hvUF3Jmb0k486 kx0gXpBTaBnX9WZCHP90ou4BdWFf82sMkW4SqWwbWQ== X-Received: by 2002:a7b:c210:: with SMTP id x16mr47411wmi.37.1600700307697; Mon, 21 Sep 2020 07:58:27 -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: <20200921143059.GO2139@willie-the-truck> From: Alexander Potapenko Date: Mon, 21 Sep 2020 16:58:16 +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" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 pointe= r > > 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 declar= e > > 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 virt= ual > 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. > An alternative approach would be to patch in the address at runtime, with > something like a static key to swizzle off the direct __kfence_pool load > once we're up and running. IIUC there's no such thing as address patching in the kernel at the moment, at least static keys work differently? I am not sure how much we need to randomize this address range (we don't on x86 anyway). > Will > > -- > You received this message because you are subscribed to the Google Groups= "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to kasan-dev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgi= d/kasan-dev/20200921143059.GO2139%40willie-the-truck. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg