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,URIBL_BLOCKED, 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 4014AC43466 for ; Mon, 21 Sep 2020 14:58:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C86662075E for ; Mon, 21 Sep 2020 14:58:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="pihm+3yZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C86662075E 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 4CFDA90007B; Mon, 21 Sep 2020 10:58:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 47E55900072; Mon, 21 Sep 2020 10:58:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36D1D90007B; Mon, 21 Sep 2020 10:58:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0034.hostedemail.com [216.40.44.34]) by kanga.kvack.org (Postfix) with ESMTP id 0A31E900072 for ; Mon, 21 Sep 2020 10:58:30 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C52B4180AD802 for ; Mon, 21 Sep 2020 14:58:29 +0000 (UTC) X-FDA: 77287374738.03.taste50_57101d027146 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id A2DC928A4EB for ; Mon, 21 Sep 2020 14:58:29 +0000 (UTC) X-HE-Tag: taste50_57101d027146 X-Filterd-Recvd-Size: 6605 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 14:58:29 +0000 (UTC) Received: by mail-wm1-f68.google.com with SMTP id d4so12446611wmd.5 for ; Mon, 21 Sep 2020 07:58:28 -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=b/bhOK2UropScfWQKaLgr2DsQueZfO/V8ZpgzX5vettoYmo36zzknK06206sw/1R1l vWrBIGUF0RcSpVQ5qHzvJ250R2bmP3d+5Y4BfMAgSGaO5idJKq2qTxjwGS2PV8ql/rDO iOzNRAJm7Si88UPSs6+SHrraZpLpP+vR03eQE9X4OUsoie1TNelF1XAhlxlXeRWFoEKg QRwTCni3RPimxZRHWr1Z6H19YJrIvx30jJjQuS4jSTnZUdTC607TpMsgkBmXeIWbKG8w 3CD80myMFLw3xhCUIZEZ2X79mYe6A3QJ9w297Cfd5TCBz+QY0HOrbjYZBd0zAYkqVcpP xFmw== X-Gm-Message-State: AOAM533PrUZlIj9klg5KOIN7YTooubk9WCfD1j5vfQj21GS2OC5/w8oT RlcZfojx/g4342CqyL5b97R0KjTTq50TBRwn6PwM6A== X-Google-Smtp-Source: ABdhPJz9PSmNZXFkAIl8F7mMeI1IkMs29iiL7Fx77FGziAuV1SJmSBTtJ48EjMLqI0Oj5jqQ4/LlPfa8EPlyupGmeWM= 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 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: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