linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Axtens <dja@axtens.net>
To: Balbir Singh <bsingharora@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linuxppc-dev@lists.ozlabs.org, kasan-dev@googlegroups.com,
	christophe.leroy@csgroup.eu, aneesh.kumar@linux.ibm.com
Subject: Re: [PATCH v11 1/6] kasan: allow an architecture to disable inline instrumentation
Date: Mon, 22 Mar 2021 11:29:32 +1100	[thread overview]
Message-ID: <87r1k8av4j.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <20210320014606.GB77072@balbir-desktop>

Balbir Singh <bsingharora@gmail.com> writes:

> On Sat, Mar 20, 2021 at 01:40:53AM +1100, Daniel Axtens wrote:
>> For annoying architectural reasons, it's very difficult to support inline
>> instrumentation on powerpc64.
>
> I think we can expand here and talk about how in hash mode, the vmalloc
> address space is in a region of memory different than where kernel virtual
> addresses are mapped. Did I recollect the reason correctly?

I think that's _a_ reason, but for radix mode (which is all I support at
the moment), the reason is a bit simpler. We call into generic code like
the DT parser and printk when we have translations off. The shadow
region lives at c00e.... which is not part of the linear mapping, so if
you try to access the shadow while in real mode you will access unmapped
memory and (at least on PowerNV) take a machine check.

>> 
>> Add a Kconfig flag to allow an arch to disable inline. (It's a bit
>> annoying to be 'backwards', but I'm not aware of any way to have
>> an arch force a symbol to be 'n', rather than 'y'.)
>> 
>> We also disable stack instrumentation in this case as it does things that
>> are functionally equivalent to inline instrumentation, namely adding
>> code that touches the shadow directly without going through a C helper.
>> 
>> Signed-off-by: Daniel Axtens <dja@axtens.net>
>> ---
>>  lib/Kconfig.kasan | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>> 
>> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
>> index cffc2ebbf185..7e237dbb6df3 100644
>> --- a/lib/Kconfig.kasan
>> +++ b/lib/Kconfig.kasan
>> @@ -12,6 +12,9 @@ config HAVE_ARCH_KASAN_HW_TAGS
>>  config HAVE_ARCH_KASAN_VMALLOC
>>  	bool
>>  
>> +config ARCH_DISABLE_KASAN_INLINE
>> +	def_bool n
>> +
>
> Some comments on what arch's want to disable kasan inline would
> be helpful and why.

Sure, added.

Kind regards,
Daniel



  reply	other threads:[~2021-03-22  0:29 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-19 14:40 [PATCH v11 0/6] KASAN for powerpc64 radix Daniel Axtens
2021-03-19 14:40 ` [PATCH v11 1/6] kasan: allow an architecture to disable inline instrumentation Daniel Axtens
2021-03-20  1:46   ` Balbir Singh
2021-03-22  0:29     ` Daniel Axtens [this message]
2021-03-22 11:08       ` Michael Ellerman
2021-03-22  8:18   ` Marco Elver
2021-03-19 14:40 ` [PATCH v11 2/6] kasan: allow architectures to provide an outline readiness check Daniel Axtens
2021-03-22  8:17   ` Marco Elver
2021-03-19 14:40 ` [PATCH v11 3/6] kasan: define and use MAX_PTRS_PER_* for early shadow tables Daniel Axtens
2021-03-19 14:40 ` [PATCH v11 4/6] kasan: Document support on 32-bit powerpc Daniel Axtens
2021-03-19 14:40 ` [PATCH v11 5/6] powerpc/mm/kasan: rename kasan_init_32.c to init_32.c Daniel Axtens
2021-03-19 14:40 ` [PATCH v11 6/6] powerpc: Book3S 64-bit outline-only KASAN support Daniel Axtens
2021-03-20  6:02   ` Balbir Singh
2021-03-22  0:55     ` Daniel Axtens
2021-03-22  2:59       ` Balbir Singh
2021-03-22  5:52         ` Daniel Axtens
2021-03-22 15:14   ` Christophe Leroy
2021-04-21 12:29   ` Christophe Leroy
2021-03-20  1:40 ` [PATCH v11 0/6] KASAN for powerpc64 radix Balbir Singh
2021-03-22 14:32 ` Christophe Leroy
2021-03-23  1:21   ` Daniel Axtens
2021-03-23 13:27     ` Christophe Leroy
2021-03-29 23:53       ` Michael Ellerman

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=87r1k8av4j.fsf@dja-thinkpad.axtens.net \
    --to=dja@axtens.net \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=bsingharora@gmail.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.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).