[PATCH 0/5 v11] KASan for Arm

[Florian Fainelli]

On 7/1/2020 4:03 PM, Ard Biesheuvel wrote
> 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?

It does not look like we can go that far, the last debug prints I can
get are:

[    0.000000] kasan: kasan_pte_populate: p: ee002000, addr: 0xb7bef000
[    0.000000] kasan: kasan_pte_populate: memset done
[    0.000000] kasan: kasan_pte_populate: entry: 0xc000002e00271f
[    0.000000] kasan: kasan_pte_populate: p: ee001000, addr: 0xb7bf0000
[    0.000000] kasan: kasan_pte_populate: memset done
[    0.000000] kasan: kasan_pte_populate: entry: 0xc000002e00171f
[    0.000000] kasan: kasan_pte_populate: p: ee000000, addr: 0xb7bf1000
[    0.000000] kasan: kasan_pte_populate: memset done
[    0.000000] kasan: kasan_pte_populate: entry: 0xc000002e00071f
[    0.000000] 8<--- cut here ---
[    0.000000] Unable to handle kernel paging request at virtual address
bcbffe00
[    0.000000] pgd = (ptrval)
[    0.000000] [bcbffe00] *pgd=80000000006003, *pmd=00000000
[    0.000000] Internal error: Oops: 206 [#1] SMP ARM

The next one would be 0xb7bf2000 which is ~79MB lower than 0xbc800000.
Full log is attached.
--
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kasan.log.gz
Type: application/x-gzip
Size: 29282 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20200702/23a90eca/attachment-0001.bin>