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=-17.9 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 C750FC47420 for ; Tue, 29 Sep 2020 17:04:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0F720208FE for ; Tue, 29 Sep 2020 17:04:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Kj6x+I9c" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0F720208FE 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 325916B005C; Tue, 29 Sep 2020 13:04:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D6286B005D; Tue, 29 Sep 2020 13:04:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C4136B006C; Tue, 29 Sep 2020 13:04:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id 061D06B005C for ; Tue, 29 Sep 2020 13:04:46 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BAC35180AD804 for ; Tue, 29 Sep 2020 17:04:45 +0000 (UTC) X-FDA: 77316723330.05.food71_2a0af2c2718b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id A45961801587C for ; Tue, 29 Sep 2020 17:04:45 +0000 (UTC) X-HE-Tag: food71_2a0af2c2718b X-Filterd-Recvd-Size: 8317 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Sep 2020 17:04:45 +0000 (UTC) Received: by mail-wm1-f68.google.com with SMTP id k18so5585632wmj.5 for ; Tue, 29 Sep 2020 10:04:44 -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=Q2qSwq54NZdSyl2veBn7BJhqFUUK7iFcl9H/GTVRA5E=; b=Kj6x+I9cpVOamlCJIgk428ZZjQD3Ram2H3tsw6dNDyvgDRU3/KFlN90ns697nKZWu7 RzzEqhATAxXA0SrIWPrYoME1NRaW8XZh7zPOUdsDBaL7r+XSn/wUhDXpZaTSoCVGnmRt oYAKDo7MMsMDeqmLAEHqtr19kyIB9LXuipTQL0fHRpIoWgVv8KWm8Y1pUm0UmlH9XfHw TZIbVllK4uZTzqDNSv3vaoGJM+CKHu0KwPJ5Nsn6Scz88EIIJKCklV6TtMW9QFNHsEny k7kdHOq0TIM/DR0b2ODgOjiqqwyVZF1qhZEndTBkhrTdYO96wv4TpsS1PVLOf+GQrGoe y/TA== 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=Q2qSwq54NZdSyl2veBn7BJhqFUUK7iFcl9H/GTVRA5E=; b=CVwHUq06+zjzrBU8et6FziPl/910uakvXcVW9miVHoUvMMnWsfA3jZ/OKxj0FoMKah GZkI74LRQmDfDJydCczejARYSOtCJPeFeWn2Oa/+vfbvoKvkBt7JhjhNWK4lhDMrkbjJ VKv+Y75OP+qGUkK6z86DmDVv92iNWMrqO5I8YHuKUQ/itQ9bUxRlRYX7KAuwzOFAfEC/ Gs9UR83aNAspneYxBV5gNPxGHW9mc9bK6+8J7dHEyWcgvPU61lC6XTzwY/K9zZBpVFmY +SCMpfbNIVA7CvvnFpic8ouQy2LmGO1z/r1PZU6+M+iixCgBCRXoxBan3gHq7ERRSvgg Rj1g== X-Gm-Message-State: AOAM532TACb+ytb2wYG9yxiabPK+xBi8NX95x/SQJSxoaSHIujoIaJk4 IwbIvNBl47lVIeXSeqI7WrrpinXY7cTJn92Nytilfg== X-Google-Smtp-Source: ABdhPJwOscngdOaqUBSevTARqhUo/ERncaL04LQq5TSuhVCcud+q5tyftAYFQVDVPNIYRkTJhAhEM/eqsuDS5QzBDsI= X-Received: by 2002:a7b:c749:: with SMTP id w9mr5250095wmk.29.1601399083707; Tue, 29 Sep 2020 10:04:43 -0700 (PDT) MIME-Version: 1.0 References: <20200921132611.1700350-1-elver@google.com> <20200921132611.1700350-4-elver@google.com> <20200929142752.GD53442@C02TD0UTHF1T.local> In-Reply-To: <20200929142752.GD53442@C02TD0UTHF1T.local> From: Alexander Potapenko Date: Tue, 29 Sep 2020 19:04:32 +0200 Message-ID: Subject: Re: [PATCH v3 03/10] arm64, kfence: enable KFENCE for ARM64 To: Mark Rutland 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 , Pekka Enberg , Peter Zijlstra , sjpark@amazon.com, Thomas Gleixner , Vlastimil Babka , Will Deacon , "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 Tue, Sep 29, 2020 at 4:28 PM Mark Rutland 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. > > --- > > arch/arm64/Kconfig | 1 + > > arch/arm64/include/asm/kfence.h | 39 +++++++++++++++++++++++++++++++++ > > arch/arm64/mm/fault.c | 4 ++++ > > 3 files changed, 44 insertions(+) > > create mode 100644 arch/arm64/include/asm/kfence.h > > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > > index 6d232837cbee..1acc6b2877c3 100644 > > --- a/arch/arm64/Kconfig > > +++ b/arch/arm64/Kconfig > > @@ -132,6 +132,7 @@ config ARM64 > > select HAVE_ARCH_JUMP_LABEL_RELATIVE > > select HAVE_ARCH_KASAN if !(ARM64_16K_PAGES && ARM64_VA_BITS_48) > > select HAVE_ARCH_KASAN_SW_TAGS if HAVE_ARCH_KASAN > > + select HAVE_ARCH_KFENCE if (!ARM64_16K_PAGES && !ARM64_64K_PAGES) > > select HAVE_ARCH_KGDB > > select HAVE_ARCH_MMAP_RND_BITS > > select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT > > diff --git a/arch/arm64/include/asm/kfence.h b/arch/arm64/include/asm/k= fence.h > > new file mode 100644 > > index 000000000000..608dde80e5ca > > --- /dev/null > > +++ b/arch/arm64/include/asm/kfence.h > > @@ -0,0 +1,39 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > + > > +#ifndef __ASM_KFENCE_H > > +#define __ASM_KFENCE_H > > + > > +#include > > +#include > > +#include > > + > > +#include > > + > > +#define KFENCE_SKIP_ARCH_FAULT_HANDLER "el1_sync" > > + > > +/* > > + * FIXME: Support HAVE_ARCH_KFENCE_STATIC_POOL: Use the statically all= ocated > > + * __kfence_pool, to avoid the extra pointer load for is_kfence_addres= s(). By > > + * default, however, we do not have struct pages for static allocation= s. > > + */ > > + > > +static inline bool arch_kfence_initialize_pool(void) > > +{ > > + const unsigned int num_pages =3D ilog2(roundup_pow_of_two(KFENCE_= POOL_SIZE / PAGE_SIZE)); > > + struct page *pages =3D alloc_pages(GFP_KERNEL, num_pages); > > + > > + if (!pages) > > + return false; > > + > > + __kfence_pool =3D page_address(pages); > > + return true; > > +} > > + > > +static inline bool kfence_protect_page(unsigned long addr, bool protec= t) > > +{ > > + set_memory_valid(addr, 1, !protect); > > + > > + return true; > > +} > > This is only safe if the linear map is force ot page granularity. That's > the default with rodata=3Dfull, but this is not always the case, so this > will need some interaction with the MMU setup in arch/arm64/mm/mmu.c. On x86 we ensure this by reallocating the necessary page tables. But looks like your suggestion is what we need for arm64 as long as we also want virt_to_page() to work for our pool. It's still unclear to me whether a carveout you suggest can be placed at a fixed (known at link time) address, as the main point of this dance is to remove memory accesses from is_kfence_addr(). > Thanks, > Mark. --=20 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