On Wed, 14 Oct 2020 at 01:57, Florian Fainelli [off-list ref] wrote:

On 10/13/20 11:00 AM, Ard Biesheuvel wrote:

quoted

On Tue, 13 Oct 2020 at 19:57, Florian Fainelli [off-list ref] wrote:

quoted

On 10/12/20 11:34 PM, Ard Biesheuvel wrote:

quoted

On Tue, 13 Oct 2020 at 05:22, Florian Fainelli [off-list ref] wrote:

quoted

On 10/12/2020 2:56 PM, Linus Walleij wrote:

quoted

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@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,

quoted

[    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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel