[PATCH 0/5 v15] KASan for Arm

[Ard Biesheuvel]

On Wed, 14 Oct 2020 at 01:57, Florian Fainelli <f.fainelli at gmail.com> wrote:
>
> On 10/13/20 11:00 AM, Ard Biesheuvel wrote:
> > 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?
>
> Yes, I have just incorrectly applied the patch not sure how... it does
> work correctly now on all of my systems, thanks a lot!

Excellent! Thanks for double checking.