[PATCH 0/5 v11] KASan for Arm

[Ard Biesheuvel]

On Thu, 2 Jul 2020 at 00:28, Florian Fainelli <f.fainelli at gmail.com> wrote:
>
>
>
> On 7/1/2020 2:41 PM, Ard Biesheuvel wrote:
> > On Wed, 1 Jul 2020 at 22:16, Florian Fainelli <f.fainelli at gmail.com> wrote:
> >>
> >>
> >>
> >> On 7/1/2020 5:09 AM, Ard Biesheuvel wrote:
> >>>
> >>> I pushed these changes and a few more to
> >>>
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kasan-v11
> >>
> >> This branch works a bit better however I am still seeing some boot
> >> errors (some sample logs attached) similar to Linus' branch.
> >>
> >
> > These crashes are all identical, they all crash on the bc9ffe00 shadow
> > address not being backed by early shadow memory.
> >
> > That value has all bits PTE index bits set to 1, and given how
> > memblock usually allocates top down, it means we are allocating page
> > by page and calling check_memory_region() on it during the memset()
> > until the point where we hit a PMD that is not set, covering the
> > window bc800000-bc9fffff
> >
> > Are there any memory reservations in the range ec000000-ecffffff ?
>
> Not that I can see according to memblock=debug:
>

Yeah I actually meant the PA equivalent of that, i.e., 2c000000-2cffffff

> [    0.000000]  reserved.cnt  = 0x6
> [    0.000000]  reserved[0x0]   [0x0000000000000000-0x0000000000000fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  reserved[0x1]   [0x0000000000003000-0x0000000000007fff],
> 0x0000000000005000 bytes flags: 0x0
> [    0.000000]  reserved[0x2]   [0x0000000000200000-0x0000000002dd0b7f],
> 0x0000000002bd0b80 bytes flags: 0x0
> [    0.000000]  reserved[0x3]   [0x0000000006400000-0x00000000065fffff],
> 0x0000000000200000 bytes flags: 0x0
> [    0.000000]  reserved[0x4]   [0x000000000e415000-0x000000000e41960b],
> 0x000000000000460c bytes flags: 0x0
> [    0.000000]  reserved[0x5]   [0x000000007f000000-0x000000007fffffff],
> 0x0000000001000000 bytes flags: 0x0
>
> [    0.000000]  reserved.cnt  = 0x7
> [    0.000000]  reserved[0x0]   [0x0000000000000000-0x0000000000000fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  reserved[0x1]   [0x0000000000003000-0x0000000000007fff],
> 0x0000000000005000 bytes flags: 0x0
> [    0.000000]  reserved[0x2]   [0x0000000000200000-0x0000000002dd0b7f],
> 0x0000000002bd0b80 bytes flags: 0x0
> [    0.000000]  reserved[0x3]   [0x0000000006400000-0x00000000064fffff],
> 0x0000000000100000 bytes flags: 0x0
> [    0.000000]  reserved[0x4]   [0x0000000007008000-0x000000000700ffff],
> 0x0000000000008000 bytes flags: 0x0
> [    0.000000]  reserved[0x5]   [0x0000000007819000-0x000000000781e5cf],
> 0x00000000000055d0 bytes flags: 0x0
> [    0.000000]  reserved[0x6]   [0x000000003cc00000-0x000000003dbfffff],
> 0x0000000001000000 bytes flags: 0x0
>
>
> > Are you using the default vmalloc range?
>
> Yes.
>
> > Any other peculiarities in the memory layout?
>
> Not that I can think of, the memory is mapped at PA 0x0000_0000 all the
> way to 0xbfff_ffff and then all other memory is mapped at PA
> 0x1_0000_0000 and aboved.

OK, so assuming kasan_early_init() backs the entire shadow region with
zero pages correctly, we are losing the mapping somewhere between
there and kasan_init(), and there are quite a number of
create_mapping() calls in the meantime.

So if you have cycles to spend on this, do you mind instrumenting
create_mapping() and see whether any of the ranges that are
(re`)mapped come within 2 MB of bc800000-bc9fffff?