All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Axtens <dja@axtens.net>
To: Balbir Singh <bsingharora@gmail.com>
Cc: aneesh.kumar@linux.ibm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, kasan-dev@googlegroups.com,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v11 6/6] powerpc: Book3S 64-bit outline-only KASAN support
Date: Mon, 22 Mar 2021 11:55:08 +1100	[thread overview]
Message-ID: <87o8fcatxv.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <20210320060259.GF77072@balbir-desktop>

Hi Balbir,

> Could you highlight the changes from
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20170729140901.5887-1-bsingharora@gmail.com/?
>
> Feel free to use my signed-off-by if you need to and add/update copyright
> headers if appropriate.

There's not really anything in common any more:

 - ppc32 KASAN landed, so there was already a kasan.h for powerpc, the
   explicit memcpy changes, the support for non-instrumented files,
   prom_check.sh, etc. all already landed.

 - I locate the shadow region differently and don't resize any virtual
   memory areas.

 - The ARCH_DEFINES_KASAN_ZERO_PTE handling changed upstream and our
   handling for that is now handled more by patch 3.

 - The outline hook is now an inline function rather than a #define.

 - The init function has been totally rewritten as it's gone from
   supporting real mode to not supporting real mode and back.

 - The list of non-instrumented files has grown a lot.

 - There's new stuff: stack walking is now safe, KASAN vmalloc support
   means modules are better supported now, ptdump works, and there's
   documentation.

It's been a while now, but I don't think when I started this process 2
years ago that I directly reused much of your code. So I'm not sure that
a signed-off-by makes sense here? Would a different tag (Originally-by?)
make more sense?

>> + * The shadow ends before the highest accessible address
>> + * because we don't need a shadow for the shadow. Instead:
>> + * c00e000000000000 << 3 + a80e 0000 0000 0000 000 = c00fc00000000000
>
> The comment has one extra 0 in a80e.., I did the math and had to use
> the data from the defines :)

3 extra 0s, even! Fixed.

>> +void __init kasan_init(void)
>> +{
>> +	/*
>> +	 * We want to do the following things:
>> +	 *  1) Map real memory into the shadow for all physical memblocks
>> +	 *     This takes us from c000... to c008...
>> +	 *  2) Leave a hole over the shadow of vmalloc space. KASAN_VMALLOC
>> +	 *     will manage this for us.
>> +	 *     This takes us from c008... to c00a...
>> +	 *  3) Map the 'early shadow'/zero page over iomap and vmemmap space.
>> +	 *     This takes us up to where we start at c00e...
>> +	 */
>> +
>
> assuming we have
> #define VMEMMAP_END R_VMEMMAP_END
> and ditto for hash we probably need
>
> 	BUILD_BUG_ON(VMEMMAP_END + KASAN_SHADOW_OFFSET != KASAN_SHADOW_END);

Sorry, I'm not sure what this is supposed to be testing? In what
situation would this trigger?

Kind regards,
Daniel

>
> Looks good otherwise, I've not been able to test it yet
>
> Balbir Singh.

WARNING: multiple messages have this Message-ID (diff)
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 6/6] powerpc: Book3S 64-bit outline-only KASAN support
Date: Mon, 22 Mar 2021 11:55:08 +1100	[thread overview]
Message-ID: <87o8fcatxv.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <20210320060259.GF77072@balbir-desktop>

Hi Balbir,

> Could you highlight the changes from
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20170729140901.5887-1-bsingharora@gmail.com/?
>
> Feel free to use my signed-off-by if you need to and add/update copyright
> headers if appropriate.

There's not really anything in common any more:

 - ppc32 KASAN landed, so there was already a kasan.h for powerpc, the
   explicit memcpy changes, the support for non-instrumented files,
   prom_check.sh, etc. all already landed.

 - I locate the shadow region differently and don't resize any virtual
   memory areas.

 - The ARCH_DEFINES_KASAN_ZERO_PTE handling changed upstream and our
   handling for that is now handled more by patch 3.

 - The outline hook is now an inline function rather than a #define.

 - The init function has been totally rewritten as it's gone from
   supporting real mode to not supporting real mode and back.

 - The list of non-instrumented files has grown a lot.

 - There's new stuff: stack walking is now safe, KASAN vmalloc support
   means modules are better supported now, ptdump works, and there's
   documentation.

It's been a while now, but I don't think when I started this process 2
years ago that I directly reused much of your code. So I'm not sure that
a signed-off-by makes sense here? Would a different tag (Originally-by?)
make more sense?

>> + * The shadow ends before the highest accessible address
>> + * because we don't need a shadow for the shadow. Instead:
>> + * c00e000000000000 << 3 + a80e 0000 0000 0000 000 = c00fc00000000000
>
> The comment has one extra 0 in a80e.., I did the math and had to use
> the data from the defines :)

3 extra 0s, even! Fixed.

>> +void __init kasan_init(void)
>> +{
>> +	/*
>> +	 * We want to do the following things:
>> +	 *  1) Map real memory into the shadow for all physical memblocks
>> +	 *     This takes us from c000... to c008...
>> +	 *  2) Leave a hole over the shadow of vmalloc space. KASAN_VMALLOC
>> +	 *     will manage this for us.
>> +	 *     This takes us from c008... to c00a...
>> +	 *  3) Map the 'early shadow'/zero page over iomap and vmemmap space.
>> +	 *     This takes us up to where we start at c00e...
>> +	 */
>> +
>
> assuming we have
> #define VMEMMAP_END R_VMEMMAP_END
> and ditto for hash we probably need
>
> 	BUILD_BUG_ON(VMEMMAP_END + KASAN_SHADOW_OFFSET != KASAN_SHADOW_END);

Sorry, I'm not sure what this is supposed to be testing? In what
situation would this trigger?

Kind regards,
Daniel

>
> Looks good otherwise, I've not been able to test it yet
>
> Balbir Singh.


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

Thread overview: 34+ 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-20  1:46     ` Balbir Singh
2021-03-22  0:29     ` Daniel Axtens
2021-03-22  0:29       ` Daniel Axtens
2021-03-22 11:08       ` Michael Ellerman
2021-03-22 11:08         ` Michael Ellerman
2021-03-22  8:18   ` Marco Elver
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-19 14:40   ` Daniel Axtens
2021-03-22  8:17   ` Marco Elver
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-20  6:02     ` Balbir Singh
2021-03-22  0:55     ` Daniel Axtens [this message]
2021-03-22  0:55       ` Daniel Axtens
2021-03-22  2:59       ` Balbir Singh
2021-03-22  2:59         ` Balbir Singh
2021-03-22  5:52         ` Daniel Axtens
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-20  1:40   ` 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=87o8fcatxv.fsf@dja-thinkpad.axtens.net \
    --to=dja@axtens.net \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=bsingharora@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.