[PATCH 0/6 v14] KASan for Arm

[Ard Biesheuvel]

On Thu, 1 Oct 2020 at 21:19, Florian Fainelli <f.fainelli at gmail.com> wrote:
>
>
>
> On 10/1/2020 8:22 AM, Linus Walleij wrote:
> > This is the 14th iteration of KASan for ARM/Aarch32.
> >
> > I have added one patch in the beginning of the series to
> > fix the issue when the DTB (often attached DTB) ends up
> > in lowmem. It also amends ARM to copy the device tree
> > instead of just unflattening it and using it from where
> > it is.
> >
> > 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. If you inspect patch 1/6 you can
> > see what has been going on for me. My hypothesis about
> > what was going on was mostly right.
> >
> > 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
>
> It does appear to be slight better, although all platforms that I have
> where memory starts at physical address 0 cannot boot, attached logs
> which are all more or less the same.
>
> The physical memory map looks like this:
>
> 0..3GB -> DRAM
> 3GB..4GB -> Registers, Boot ROM, Boot SRAM
> 4GB..12GB -> DRAM extension
>
> Do any of the platforms you use for testing have a similar memory map?
> Could you try to contrive a QEMU machine to have something similar in
> case that helps reproducing these failures?
>

I am getting very similar failures on a Raspberry Pi4 booting in
32-bit mode from U-boot+EFI

Full log attached.

I will try to dig a bit deeper.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screen-exchange
Type: application/octet-stream
Size: 13476 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20201003/17c8a9b3/attachment-0001.obj>