linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Rob Herring <robh@kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Abbott Liu <liuwenliang@huawei.com>,
	Russell King <linux@armlinux.org.uk>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/5 v2] KASan for ARM
Date: Thu, 4 Jun 2020 19:01:35 +0200	[thread overview]
Message-ID: <CAMj1kXFvbn3UAAO+zB9J79Prjgx4-xwjJ64VnOj2a_nyOQQDqQ@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXErHqaQod5nQCypLvyWET-K2-CEKvcGMPYzgfb=mgKK0A@mail.gmail.com>

On Thu, 4 Jun 2020 at 14:10, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 4 Jun 2020 at 13:26, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Thu, 4 Jun 2020 at 11:24, Linus Walleij <linus.walleij@linaro.org> wrote:
> > >
> > > On Wed, Jun 3, 2020 at 10:45 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > > On Mon, Jun 1, 2020 at 6:37 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> > > >
> > > > > This branch got me a bit further,
> > > >
> > > > Thanks, at least we get improvements. :)
> > > >
> > > > > but still failed to fully initialize
> > > > > (see attached kasan.log), on another platform with a slightly different
> > > > > memory map, I ended up getting a different error (kasan2.log).
> > > >
> > > > I have this error too on a Qualcomm board, it is what I report
> > > > in the cover letter, that if I load the kernel into 0x40200000
> > > > this happens but when I load it into 0x50000000 it does not
> > > > happen.
> > >
> > > So this is what happens to me, even after I try to de-instrument
> > > the DT parsing code (maybe I do it all wrong...)
> > > This is done with that patch:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/commit/?h=kasan-apq8060-test&id=1cd83357f3c35b037400f6ec2547eeff074c578c
> > >
> > > If I boot from physical memory at 0x40200000
> > > fastboot --base 40200000 --cmdline "console=ttyMSM0,115200,n8" boot zImage
> > >
> > > kasan: populating shadow for b7040000, b75c0000
> > > kasan: populating shadow for b8000000, bb000000
> > > kasan: populating shadow for b6e00000, b7000000
> > > kasan: Kernel address sanitizer initialized
> > > 8<--- cut here ---
> > > Unable to handle kernel paging request at virtual address c30050b0
> > > pgd = (ptrval)
> > > [c30050b0] *pgd=00000000c
> > > Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> > > Modules linked in:c
> > > CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-00011-g1cd83357f3c3 #34
> > > Hardware name: Generic DT based system
> > > PC is at fdt_check_header+0x0/0x168
> > > LR is at __unflatten_device_tree+0x6c/0x338
> > > pc : [<c08e6968>]    lr : [<c0d698a8>]    psr: 60000093
> > > sp : c1e03db8  ip : cffffee0  fp : fffff000
> > > r10: 00000000  r9 : c2646000  r8 : 00000000
> > > r7 : c30050b0  r6 : c192e9e4  r5 : c19492e8  r4 : c21d7448
> > > r3 : 00000000  r2 : c2646000  r1 : 00000000  r0 : c30050b0
> > > (...)
> > > [<c08e6968>] (fdt_check_header) from [<c192e9e4>]
> > > (early_init_dt_alloc_memory_arch+0x0/0x64)
> > > [<c192e9e4>] (early_init_dt_alloc_memory_arch) from [<c1930264>]
> > > (unflatten_device_tree+0x34/0x44)
> > > [<c1930264>] (unflatten_device_tree) from [<c1905794>] (setup_arch+0xac4/0xde8)
> > > [<c1905794>] (setup_arch) from [<c1900b98>] (start_kernel+0xd8/0x634)
> > > [<c1900b98>] (start_kernel) from [<00000000>] (0x0)
> > > Code: e3a00020 e12fff1e e3a0001c e12fff1e (e5901000)
> > > random: get_random_bytes called from print_oops_end_marker+0x38/0x50
> > > with crng_init=0
> > > ---[ end trace 0000000000000000 ]---
> > > Kernel panic - not syncing: Attempted to kill the idle task!
> > > ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
> > >
> >
> > I don't think we ever check whether the ATAGS/DTB pointer points into
> > memory that is described to the kernel as unreserved lowmem. We simply
> > call phys_to_virt() on it [in setup_machine_fdt()], and assume that by
> > the time we call unflatten_device_tree(), the same virtual address
> > still points to the DT contents.
> >

OK, so this is definitely not the issue. I am seeing very similar
issues, but in different places (two examples below)

What is notable here is that in both cases, a sizable chunk of memory
has one stack frame's worth of shadow bytes right in the middle. I
spent some time trying to figure out what is going on here, but I am
not a KASAN expert, so I am struggling a bit. Are we sure that all the
shadow is mapped correctly without physical pages being mapped more
than once?




[    0.000000] ==================================================================
[    0.000000] BUG: KASAN: stack-out-of-bounds in
memblock_alloc_try_nid+0x108/0x144
[    0.000000] Write of size 19104 at addr e95c2560 by task swapper/0
[    0.000000]
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0+ #60
[    0.000000] Hardware name: Generic DT based system
[    0.000000] [<c0317634>] (unwind_backtrace) from [<c030f338>]
(show_stack+0x10/0x14)
[    0.000000] [<c030f338>] (show_stack) from [<c0905130>]
(dump_stack+0xc4/0xdc)
[    0.000000] [<c0905130>] (dump_stack) from [<c053b238>]
(print_address_description.constprop.0+0x34/0x444)
[    0.000000] [<c053b238>] (print_address_description.constprop.0)
from [<c053b844>] (kasan_report+0x158/0x174)
[    0.000000] [<c053b844>] (kasan_report) from [<c053c24c>]
(check_memory_region+0x94/0x1a4)
[    0.000000] [<c053c24c>] (check_memory_region) from [<c053a640>]
(memset+0x20/0x3c)
[    0.000000] [<c053a640>] (memset) from [<c242fa78>]
(memblock_alloc_try_nid+0x108/0x144)
[    0.000000] [<c242fa78>] (memblock_alloc_try_nid) from [<c24c857c>]
(early_init_dt_alloc_memory_arch+0x30/0x60)
[    0.000000] [<c24c857c>] (early_init_dt_alloc_memory_arch) from
[<c128cd3c>] (__unflatten_device_tree+0x5c/0x11c)
[    0.000000] [<c128cd3c>] (__unflatten_device_tree) from
[<c24c9c88>] (unflatten_device_tree+0x34/0x44)
[    0.000000] [<c24c9c88>] (unflatten_device_tree) from [<c2405a4c>]
(setup_arch+0xc00/0x10f4)
[    0.000000] [<c2405a4c>] (setup_arch) from [<c2400c2c>]
(start_kernel+0xd4/0x610)
[    0.000000] [<c2400c2c>] (start_kernel) from [<00000000>] (0x0)
[    0.000000]
[    0.000000] The buggy address belongs to the page:
[    0.000000] page:efd24840 refcount:1 mapcount:0 mapping:00000000 index:0x0
[    0.000000] flags: 0x0()
[    0.000000] raw: 00000000 efd24844 efd24844 00000000 00000000
00000000 ffffffff 00000001
[    0.000000] page dumped because: kasan: bad access detected
[    0.000000]
[    0.000000] Memory state around the buggy address:
[    0.000000]  e95c3c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]  e95c3c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000] >e95c3d00: f1 f1 f1 f1 f1 f1 04 f2 04 f3 f3 f3 00 00 00 00
[    0.000000]            ^
[    0.000000]  e95c3d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]  e95c3e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000] ==================================================================

[   50.235136] ==================================================================
[   50.238107] BUG: KASAN: stack-out-of-bounds in blk_add_partitions+0x1e8/0x6f8
[   50.239318] Write of size 32768 at addr f08c6000 by task swapper/0/1
[   50.240226]
[   50.241432] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0+ #60
[   50.242402] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
[   50.244206] [<c0317634>] (unwind_backtrace) from [<c030f338>]
(show_stack+0x10/0x14)
[   50.245566] [<c030f338>] (show_stack) from [<c0905130>]
(dump_stack+0xc4/0xdc)
[   50.246823] [<c0905130>] (dump_stack) from [<c053b384>]
(print_address_description.constprop.0+0x180/0x444)
[   50.248429] [<c053b384>] (print_address_description.constprop.0)
from [<c053b844>] (kasan_report+0x158/0x174)
[   50.250113] [<c053b844>] (kasan_report) from [<c053c24c>]
(check_memory_region+0x94/0x1a4)
[   50.251495] [<c053c24c>] (check_memory_region) from [<c053a640>]
(memset+0x20/0x3c)
[   50.252787] [<c053a640>] (memset) from [<c0868954>]
(blk_add_partitions+0x1e8/0x6f8)
[   50.254172] [<c0868954>] (blk_add_partitions) from [<c05aa56c>]
(bdev_disk_changed+0x94/0x118)
[   50.255630] [<c05aa56c>] (bdev_disk_changed) from [<c05ab140>]
(__blkdev_get+0x460/0x748)
[   50.257091] [<c05ab140>] (__blkdev_get) from [<c08649b4>]
(__device_add_disk+0x718/0x808)
[   50.258649] [<c08649b4>] (__device_add_disk) from [<c24b12ac>]
(brd_init+0x158/0x234)
[   50.259989] [<c24b12ac>] (brd_init) from [<c0302630>]
(do_one_initcall+0xb4/0x30c)
[   50.261275] [<c0302630>] (do_one_initcall) from [<c2401360>]
(kernel_init_freeable+0x1f8/0x26c)
[   50.262629] [<c2401360>] (kernel_init_freeable) from [<c1545040>]
(kernel_init+0x8/0x120)
[   50.263953] [<c1545040>] (kernel_init) from [<c03001b0>]
(ret_from_fork+0x14/0x24)
[   50.265225] Exception stack(0xe88c3fb0 to 0xe88c3ff8)
[   50.266569] 3fa0:                                     00000000
00000000 00000000 00000000
[   50.268334] 3fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[   50.269970] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[   50.271241]
[   50.271821]
[   50.272268] Memory state around the buggy address:
[   50.274111]  f08cbd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   50.275302]  f08cbd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   50.276296] >f08cbe00: 00 00 00 00 f1 f1 f1 f1 04 f2 04 f2 00 f3 f3 f3
[   50.277548]                        ^
[   50.278206]  f08cbe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   50.279194]  f08cbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   50.280193] ==================================================================

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      reply	other threads:[~2020-06-04 17:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-12  0:24 [PATCH 0/5 v2] KASan for ARM Linus Walleij
2020-04-12  0:24 ` [PATCH 1/5 v2] ARM: Disable KASan instrumentation for some code Linus Walleij
2020-04-12  0:24 ` [PATCH 2/5 v2] ARM: Replace memory functions for KASan Linus Walleij
2020-04-12  0:24 ` [PATCH 3/5 v2] ARM: Define the virtual space of KASan's shadow region Linus Walleij
2020-04-12  0:24 ` [PATCH 4/5 v2] ARM: Initialize the mapping of KASan shadow memory Linus Walleij
2020-04-12  0:24 ` [PATCH 5/5 v2] ARM: Enable KASan for ARM Linus Walleij
2020-06-01  4:00 ` [PATCH 0/5 v2] " Florian Fainelli
2020-06-01  8:55   ` Linus Walleij
2020-06-01 16:36     ` Florian Fainelli
2020-06-01 16:40       ` Ard Biesheuvel
2020-06-01 16:51         ` Florian Fainelli
2020-06-03  8:45       ` Linus Walleij
2020-06-04  9:24         ` Linus Walleij
2020-06-04 11:26           ` Ard Biesheuvel
2020-06-04 12:10             ` Ard Biesheuvel
2020-06-04 17:01               ` Ard Biesheuvel [this message]

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=CAMj1kXFvbn3UAAO+zB9J79Prjgx4-xwjJ64VnOj2a_nyOQQDqQ@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=f.fainelli@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=liuwenliang@huawei.com \
    --cc=robh@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).