[PATCH 0/5 v15] KASan for Arm

[Ard Biesheuvel]

On Tue, 13 Oct 2020 at 19:57, Florian Fainelli <f.fainelli at 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 at 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 at 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?