All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	Alexander Potapenko <glider@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linuxppc-dev@lists.ozlabs.org,
	kasan-dev <kasan-dev@googlegroups.com>,
	Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH v3 3/3] powerpc/32: Add KASAN support
Date: Mon, 21 Jan 2019 09:30:27 +0100	[thread overview]
Message-ID: <CACT4Y+Z+UbN1rjHr3T5rgHpCJUknupPvEPw0SHs1-qjWBDhm3Q@mail.gmail.com> (raw)
In-Reply-To: <8d433501-a5a7-8e3b-03f7-ccdd0f8622e1@c-s.fr>

On Mon, Jan 21, 2019 at 8:17 AM Christophe Leroy
<christophe.leroy@c-s.fr> wrote:
>
>
>
> Le 15/01/2019 à 18:23, Andrey Ryabinin a écrit :
> >
> >
> > On 1/12/19 2:16 PM, Christophe Leroy wrote:
> >
> >> +KASAN_SANITIZE_early_32.o := n
> >> +KASAN_SANITIZE_cputable.o := n
> >> +KASAN_SANITIZE_prom_init.o := n
> >> +
> >
> > Usually it's also good idea to disable branch profiling - define DISABLE_BRANCH_PROFILING
> > either in top of these files or via Makefile. Branch profiling redefines if() statement and calls
> > instrumented ftrace_likely_update in every if().
> >
> >
> >
> >> diff --git a/arch/powerpc/mm/kasan_init.c b/arch/powerpc/mm/kasan_init.c
> >> new file mode 100644
> >> index 000000000000..3edc9c2d2f3e
> >
> >> +void __init kasan_init(void)
> >> +{
> >> +    struct memblock_region *reg;
> >> +
> >> +    for_each_memblock(memory, reg)
> >> +            kasan_init_region(reg);
> >> +
> >> +    pr_info("KASAN init done\n");
> >
> > Without "init_task.kasan_depth = 0;" kasan will not repot bugs.
> >
> > There is test_kasan module. Make sure that it produce reports.
> >
>
> Thanks for the review.
>
> Now I get the following very early in boot, what does that mean ?

This looks like an instrumented memset call before kasan shadow is
mapped, or kasan shadow is not zeros. Does this happen before or after
mapping of kasan_early_shadow_page?
This version seems to miss what x86 code has to clear the early shadow:

/*
* kasan_early_shadow_page has been used as early shadow memory, thus
* it may contain some garbage. Now we can clear and write protect it,
* since after the TLB flush no one should write to it.
*/
memset(kasan_early_shadow_page, 0, PAGE_SIZE);


> [    0.000000] KASAN init done
> [    0.000000]
> ==================================================================
> [    0.000000] BUG: KASAN: unknown-crash in memblock_alloc_try_nid+0xd8/0xf0
> [    0.000000] Write of size 68 at addr c7ff5a90 by task swapper/0
> [    0.000000]
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
> 5.0.0-rc2-s3k-dev-00559-g88aa407c4bce #772
> [    0.000000] Call Trace:
> [    0.000000] [c094ded0] [c016c7e4]
> print_address_description+0x1a0/0x2b8 (unreliable)
> [    0.000000] [c094df00] [c016caa0] kasan_report+0xe4/0x168
> [    0.000000] [c094df40] [c016b464] memset+0x2c/0x4c
> [    0.000000] [c094df60] [c08731f0] memblock_alloc_try_nid+0xd8/0xf0
> [    0.000000] [c094df90] [c0861f20] mmu_context_init+0x58/0xa0
> [    0.000000] [c094dfb0] [c085ca70] start_kernel+0x54/0x400
> [    0.000000] [c094dff0] [c0002258] start_here+0x44/0x9c
> [    0.000000]
> [    0.000000]
> [    0.000000] Memory state around the buggy address:
> [    0.000000]  c7ff5980: e2 a1 87 81 bd d4 a5 b5 f8 8d 89 e7 72 bc 20 24
> [    0.000000]  c7ff5a00: e7 b9 c1 c7 17 e9 b4 bd a4 d0 e7 a0 11 15 a5 b5
> [    0.000000] >c7ff5a80: b5 e1 83 a5 2d 65 31 3f f3 e5 a7 ef 34 b5 69 b5
> [    0.000000]                  ^
> [    0.000000]  c7ff5b00: 21 a5 c1 c1 b4 bf 2d e5 e5 c3 f5 91 e3 b8 a1 34
> [    0.000000]  c7ff5b80: ad ef 23 87 3d a6 ad b5 c3 c3 80 b7 ac b1 1f 37
> [    0.000000]
> ==================================================================
> [    0.000000] Disabling lock debugging due to kernel taint
> [    0.000000] MMU: Allocated 76 bytes of context maps for 16 contexts
> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8176
> [    0.000000] Kernel command line: console=ttyCPM0,115200N8
> ip=192.168.2.7:192.168.2.2::255.0.0.0:vgoip:eth0:off kgdboc=ttyCPM0
> [    0.000000] Dentry cache hash table entries: 16384 (order: 2, 65536
> bytes)
> [    0.000000] Inode-cache hash table entries: 8192 (order: 1, 32768 bytes)
> [    0.000000] Memory: 99904K/131072K available (7376K kernel code, 528K
> rwdata, 1168K rodata, 576K init, 4623K bss, 31168K reserved, 0K
> cma-reserved)
> [    0.000000] Kernel virtual memory layout:
> [    0.000000]   * 0xffefc000..0xffffc000  : fixmap
> [    0.000000]   * 0xf7c00000..0xffc00000  : kasan shadow mem
> [    0.000000]   * 0xf7a00000..0xf7c00000  : consistent mem
> [    0.000000]   * 0xf7a00000..0xf7a00000  : early ioremap
> [    0.000000]   * 0xc9000000..0xf7a00000  : vmalloc & ioremap
>
>
> Christophe

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Vyukov <dvyukov@google.com>
To: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	Linux-MM <linux-mm@kvack.org>, Paul Mackerras <paulus@samba.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 3/3] powerpc/32: Add KASAN support
Date: Mon, 21 Jan 2019 09:30:27 +0100	[thread overview]
Message-ID: <CACT4Y+Z+UbN1rjHr3T5rgHpCJUknupPvEPw0SHs1-qjWBDhm3Q@mail.gmail.com> (raw)
In-Reply-To: <8d433501-a5a7-8e3b-03f7-ccdd0f8622e1@c-s.fr>

On Mon, Jan 21, 2019 at 8:17 AM Christophe Leroy
<christophe.leroy@c-s.fr> wrote:
>
>
>
> Le 15/01/2019 à 18:23, Andrey Ryabinin a écrit :
> >
> >
> > On 1/12/19 2:16 PM, Christophe Leroy wrote:
> >
> >> +KASAN_SANITIZE_early_32.o := n
> >> +KASAN_SANITIZE_cputable.o := n
> >> +KASAN_SANITIZE_prom_init.o := n
> >> +
> >
> > Usually it's also good idea to disable branch profiling - define DISABLE_BRANCH_PROFILING
> > either in top of these files or via Makefile. Branch profiling redefines if() statement and calls
> > instrumented ftrace_likely_update in every if().
> >
> >
> >
> >> diff --git a/arch/powerpc/mm/kasan_init.c b/arch/powerpc/mm/kasan_init.c
> >> new file mode 100644
> >> index 000000000000..3edc9c2d2f3e
> >
> >> +void __init kasan_init(void)
> >> +{
> >> +    struct memblock_region *reg;
> >> +
> >> +    for_each_memblock(memory, reg)
> >> +            kasan_init_region(reg);
> >> +
> >> +    pr_info("KASAN init done\n");
> >
> > Without "init_task.kasan_depth = 0;" kasan will not repot bugs.
> >
> > There is test_kasan module. Make sure that it produce reports.
> >
>
> Thanks for the review.
>
> Now I get the following very early in boot, what does that mean ?

This looks like an instrumented memset call before kasan shadow is
mapped, or kasan shadow is not zeros. Does this happen before or after
mapping of kasan_early_shadow_page?
This version seems to miss what x86 code has to clear the early shadow:

/*
* kasan_early_shadow_page has been used as early shadow memory, thus
* it may contain some garbage. Now we can clear and write protect it,
* since after the TLB flush no one should write to it.
*/
memset(kasan_early_shadow_page, 0, PAGE_SIZE);


> [    0.000000] KASAN init done
> [    0.000000]
> ==================================================================
> [    0.000000] BUG: KASAN: unknown-crash in memblock_alloc_try_nid+0xd8/0xf0
> [    0.000000] Write of size 68 at addr c7ff5a90 by task swapper/0
> [    0.000000]
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
> 5.0.0-rc2-s3k-dev-00559-g88aa407c4bce #772
> [    0.000000] Call Trace:
> [    0.000000] [c094ded0] [c016c7e4]
> print_address_description+0x1a0/0x2b8 (unreliable)
> [    0.000000] [c094df00] [c016caa0] kasan_report+0xe4/0x168
> [    0.000000] [c094df40] [c016b464] memset+0x2c/0x4c
> [    0.000000] [c094df60] [c08731f0] memblock_alloc_try_nid+0xd8/0xf0
> [    0.000000] [c094df90] [c0861f20] mmu_context_init+0x58/0xa0
> [    0.000000] [c094dfb0] [c085ca70] start_kernel+0x54/0x400
> [    0.000000] [c094dff0] [c0002258] start_here+0x44/0x9c
> [    0.000000]
> [    0.000000]
> [    0.000000] Memory state around the buggy address:
> [    0.000000]  c7ff5980: e2 a1 87 81 bd d4 a5 b5 f8 8d 89 e7 72 bc 20 24
> [    0.000000]  c7ff5a00: e7 b9 c1 c7 17 e9 b4 bd a4 d0 e7 a0 11 15 a5 b5
> [    0.000000] >c7ff5a80: b5 e1 83 a5 2d 65 31 3f f3 e5 a7 ef 34 b5 69 b5
> [    0.000000]                  ^
> [    0.000000]  c7ff5b00: 21 a5 c1 c1 b4 bf 2d e5 e5 c3 f5 91 e3 b8 a1 34
> [    0.000000]  c7ff5b80: ad ef 23 87 3d a6 ad b5 c3 c3 80 b7 ac b1 1f 37
> [    0.000000]
> ==================================================================
> [    0.000000] Disabling lock debugging due to kernel taint
> [    0.000000] MMU: Allocated 76 bytes of context maps for 16 contexts
> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8176
> [    0.000000] Kernel command line: console=ttyCPM0,115200N8
> ip=192.168.2.7:192.168.2.2::255.0.0.0:vgoip:eth0:off kgdboc=ttyCPM0
> [    0.000000] Dentry cache hash table entries: 16384 (order: 2, 65536
> bytes)
> [    0.000000] Inode-cache hash table entries: 8192 (order: 1, 32768 bytes)
> [    0.000000] Memory: 99904K/131072K available (7376K kernel code, 528K
> rwdata, 1168K rodata, 576K init, 4623K bss, 31168K reserved, 0K
> cma-reserved)
> [    0.000000] Kernel virtual memory layout:
> [    0.000000]   * 0xffefc000..0xffffc000  : fixmap
> [    0.000000]   * 0xf7c00000..0xffc00000  : kasan shadow mem
> [    0.000000]   * 0xf7a00000..0xf7c00000  : consistent mem
> [    0.000000]   * 0xf7a00000..0xf7a00000  : early ioremap
> [    0.000000]   * 0xc9000000..0xf7a00000  : vmalloc & ioremap
>
>
> Christophe

  reply	other threads:[~2019-01-21  8:30 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-12 11:16 [PATCH v3 0/3] KASAN for powerpc/32 Christophe Leroy
2019-01-12 11:16 ` Christophe Leroy
2019-01-12 11:16 ` Christophe Leroy
2019-01-12 11:16 ` [PATCH v3 1/3] powerpc/mm: prepare kernel for KAsan on PPC32 Christophe Leroy
2019-01-12 11:16   ` Christophe Leroy
2019-01-12 11:16   ` Christophe Leroy
2019-01-14  9:34   ` Dmitry Vyukov
2019-01-14  9:34     ` Dmitry Vyukov
2019-01-14  9:34     ` Dmitry Vyukov
2019-01-15  7:27     ` Christophe Leroy
2019-01-15  7:27       ` Christophe Leroy
2019-01-15 11:14       ` Dmitry Vyukov
2019-01-15 11:14         ` Dmitry Vyukov
2019-01-15 11:14         ` Dmitry Vyukov
2019-01-15 17:07         ` Andrey Ryabinin
2019-01-15 17:07           ` Andrey Ryabinin
2019-01-15 17:10           ` Dmitry Vyukov
2019-01-15 17:10             ` Dmitry Vyukov
2019-01-15 17:10             ` Dmitry Vyukov
2019-01-15 17:25             ` Christophe Leroy
2019-01-15 17:25               ` Christophe Leroy
2019-01-16 10:03               ` Dmitry Vyukov
2019-01-16 10:03                 ` Dmitry Vyukov
2019-01-16 10:03                 ` Dmitry Vyukov
2019-01-12 11:16 ` [PATCH v3 2/3] powerpc/32: Move early_init() in a separate file Christophe Leroy
2019-01-12 11:16   ` Christophe Leroy
2019-01-12 11:16   ` Christophe Leroy
2019-01-12 11:16 ` [PATCH v3 3/3] powerpc/32: Add KASAN support Christophe Leroy
2019-01-12 11:16   ` Christophe Leroy
2019-01-12 11:16   ` Christophe Leroy
2019-01-15 17:23   ` Andrey Ryabinin
2019-01-15 17:23     ` Andrey Ryabinin
2019-01-21  7:17     ` Christophe Leroy
2019-01-21  7:17       ` Christophe Leroy
2019-01-21  8:30       ` Dmitry Vyukov [this message]
2019-01-21  8:30         ` Dmitry Vyukov
2019-01-21  8:30         ` Dmitry Vyukov
2019-01-21  8:37         ` Christophe Leroy
2019-01-21  8:37           ` Christophe Leroy
2019-01-21  9:24           ` Dmitry Vyukov
2019-01-21  9:24             ` Dmitry Vyukov
2019-01-21  9:24             ` Dmitry Vyukov
2019-01-21  9:30             ` Christophe Leroy
2019-01-21  9:30               ` Christophe Leroy
2019-01-21 10:36     ` Christophe Leroy
2019-01-21 10:36       ` Christophe Leroy
2019-01-21 12:33       ` Dmitry Vyukov
2019-01-21 12:33         ` Dmitry Vyukov
2019-01-21 12:33         ` 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=CACT4Y+Z+UbN1rjHr3T5rgHpCJUknupPvEPw0SHs1-qjWBDhm3Q@mail.gmail.com \
    --to=dvyukov@google.com \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=paulus@samba.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.