linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Marco Elver <elver@google.com>
Cc: akpm@linux-foundation.org, glider@google.com, hpa@zytor.com,
	paulmck@kernel.org, andreyknvl@google.com,
	aryabinin@virtuozzo.com, luto@kernel.org, bp@alien8.de,
	catalin.marinas@arm.com, cl@linux.com,
	dave.hansen@linux.intel.com, rientjes@google.com,
	dvyukov@google.com, edumazet@google.com,
	gregkh@linuxfoundation.org, hdanton@sina.com, mingo@redhat.com,
	jannh@google.com, Jonathan.Cameron@huawei.com, corbet@lwn.net,
	iamjoonsoo.kim@lge.com, keescook@chromium.org,
	mark.rutland@arm.com, penberg@kernel.org, peterz@infradead.org,
	sjpark@amazon.com, tglx@linutronix.de, vbabka@suse.cz,
	x86@kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
	linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org
Subject: Re: [PATCH v3 03/10] arm64, kfence: enable KFENCE for ARM64
Date: Mon, 21 Sep 2020 15:31:01 +0100	[thread overview]
Message-ID: <20200921143059.GO2139@willie-the-truck> (raw)
In-Reply-To: <20200921132611.1700350-4-elver@google.com>

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 <asm/kfence.h>. 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 <dvyukov@google.com>
> Co-developed-by: Alexander Potapenko <glider@google.com>
> Signed-off-by: Alexander Potapenko <glider@google.com>
> Signed-off-by: Marco Elver <elver@google.com>
> ---
> 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.

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?

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.

Will

  reply	other threads:[~2020-09-21 14:31 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-21 13:26 [PATCH v3 00/10] KFENCE: A low-overhead sampling-based memory safety error detector Marco Elver
2020-09-21 13:26 ` [PATCH v3 01/10] mm: add Kernel Electric-Fence infrastructure Marco Elver
2020-09-25 11:23   ` SeongJae Park
2020-09-25 11:31     ` Marco Elver
2020-09-29 12:42   ` Andrey Konovalov
2020-09-29 13:11     ` Marco Elver
2020-09-29 13:48       ` Andrey Konovalov
2020-09-29 13:49         ` Marco Elver
2020-09-29 14:01           ` Andrey Konovalov
2020-09-29 14:24   ` Mark Rutland
2020-09-29 14:51     ` Marco Elver
2020-09-29 15:05       ` Mark Rutland
2020-10-05 16:00         ` Alexander Potapenko
2020-10-05 16:49           ` Jann Horn
2020-09-29 15:51     ` Alexander Potapenko
2020-10-01 18:11       ` Mark Rutland
2020-09-21 13:26 ` [PATCH v3 02/10] x86, kfence: enable KFENCE for x86 Marco Elver
2020-09-21 13:26 ` [PATCH v3 03/10] arm64, kfence: enable KFENCE for ARM64 Marco Elver
2020-09-21 14:31   ` Will Deacon [this message]
2020-09-21 14:58     ` Alexander Potapenko
2020-09-21 15:37       ` Alexander Potapenko
2020-09-21 17:43         ` Will Deacon
2020-09-22  9:56           ` Marco Elver
2020-09-29 13:53             ` Mark Rutland
2020-09-29 16:52               ` Alexander Potapenko
2020-09-25 15:25     ` Alexander Potapenko
2020-09-29 14:02       ` Mark Rutland
2020-10-01 11:24         ` Alexander Potapenko
2020-10-01 17:57           ` Mark Rutland
2020-10-08  9:40             ` Marco Elver
2020-10-08 10:45               ` Mark Rutland
2020-10-14 19:12                 ` Marco Elver
2020-10-15 13:39                   ` Mark Rutland
2020-10-15 14:15                     ` Marco Elver
2020-09-28 11:53     ` Marco Elver
2020-09-29 14:27   ` Mark Rutland
2020-09-29 17:04     ` Alexander Potapenko
2020-09-21 13:26 ` [PATCH v3 04/10] mm, kfence: insert KFENCE hooks for SLAB Marco Elver
2020-09-21 13:26 ` [PATCH v3 05/10] mm, kfence: insert KFENCE hooks for SLUB Marco Elver
2020-09-21 13:26 ` [PATCH v3 06/10] kfence, kasan: make KFENCE compatible with KASAN Marco Elver
2020-09-29 12:20   ` Andrey Konovalov
2020-09-29 13:13     ` Alexander Potapenko
2020-09-21 13:26 ` [PATCH v3 07/10] kfence, kmemleak: make KFENCE compatible with KMEMLEAK Marco Elver
2020-09-21 13:26 ` [PATCH v3 08/10] kfence, lockdep: make KFENCE compatible with lockdep Marco Elver
2020-09-21 13:26 ` [PATCH v3 09/10] kfence, Documentation: add KFENCE documentation Marco Elver
2020-09-21 13:26 ` [PATCH v3 10/10] kfence: add test suite Marco Elver
2020-09-21 17:13   ` Paul E. McKenney
2020-09-21 17:37     ` Marco Elver
2020-09-21 17:48       ` Paul E. McKenney
2020-09-21 13:38 ` [PATCH v3 00/10] KFENCE: A low-overhead sampling-based memory safety error detector Dmitry Vyukov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200921143059.GO2139@willie-the-truck \
    --to=will@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=cl@linux.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdanton@sina.com \
    --cc=hpa@zytor.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jannh@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=penberg@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=sjpark@amazon.com \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).