Re: [PATCH 0/5 v15] KASan for Arm

From: Ard Biesheuvel <ardb@kernel.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Abbott Liu <liuwenliang@huawei.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Russell King <linux@armlinux.org.uk>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/5 v15] KASan for Arm
Date: Tue, 13 Oct 2020 20:00:30 +0200	[thread overview]
Message-ID: <CAMj1kXEBvScd0r4FGh+5wJvemZdrrPOKNh3pEBKh_e=03o6wyg@mail.gmail.com> (raw)
In-Reply-To: <10b1b6cd-3622-6c83-bd44-51ed906f2b6e@gmail.com>

On Tue, 13 Oct 2020 at 19:57, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 10/12/20 11:34 PM, Ard Biesheuvel wrote:
> > On Tue, 13 Oct 2020 at 05:22, Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>
> >>
> >>
> >> On 10/12/2020 2:56 PM, Linus Walleij wrote:
> >>> This is the 15th iteration of KASan for ARM/Aarch32.
> >>>
> >>> I dropped my fix in the beginning of the series for
> >>> Ard's more elaborate and thorough fix moving the DTB
> >>> out of the kernel linear mapped region and into its own
> >>> part of the memory.
> >>>
> >>> This fixes my particular issue on the Qualcomm APQ8060
> >>> and I hope it may also solve Florian's issue and what
> >>> Ard has been seeing. KASan should be working with
> >>> pretty much everything you throw on it, unless you
> >>> do what I did and ran it on a 64MB system, where
> >>> under some load it can run into the OOM killer for
> >>> obvious reasons.
> >>>
> >>> You are encouraged to test this patch set to find memory out
> >>> of bounds bugs with ARM32 platforms and drivers.
> >>>
> >>> There is a git branch you can pull in:
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
> >>>
> >>> This branch includes Ard's two patches.
> >>>
> >>> As Ard's patches are in Russell's patch tracker I will
> >>> put these there as well if it now works for everyone.
> >>
> >> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
> >>
> >> On Brahma-B15 (ARMv7 LPAE) and Brahma-B53 (ARMv8 in AArch32, also with
> >> LPAE). The 3 Cortex-A72 devices that I have access to all fail with the
> >> following (not related to the CPU type, more to the memory map) which I
> >> am hoping to track down later this week, I would not consider those
> >> failures to be a blocker at this point.
> >>
> >> Thanks a lot for your persistence working on this Linus, and Ard!
> >>
> >
> > Hi Florian,
> >
> >> [    0.000000] Early memory node ranges
> >> [    0.000000]   node   0: [mem 0x0000000000000000-0x00000000063fdfff]
> >> [    0.000000]   node   0: [mem 0x0000000006400000-0x000000000fffffff]
> >> [    0.000000]   node   0: [mem 0x0000000010400000-0x000000007fffffff]
> >> [    0.000000] kasan: Mapping kernel virtual memory block:
> >> c0000000-c63fe000 at shadow: b7000000-b7c7fc00
> >> [    0.000000] Kernel panic - not syncing: kasan_pte_populate failed to
> >> alloc pte for address 0xe2806000
> >
> > The issue here is that the end of the shadow region being populated is
> > not aligned to the page size, and so we never meet the stop condition
> > in kasan_pgd_populate(), and instead, we keep iterating until we run
> > out of memory.
> >
> > Does this help?
>
> Not really, the same kasan_pte_populate() failure happens for the same
> address(es).
>
> Adding memblock=debug does not allow me to boot to the point where kasan
> shadow memory gets initialized, again, not a blocker, but this sounds
> like something that may have to be looked at.

That address is not part of the shadow range, so it must be something
with the stop condition in kasan_pgd_populate(). If you have time,
could you add some printk()s in there to see what is going on?

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