Re: [PATCH 0/5 v15] KASan for Arm

From: Florian Fainelli <f.fainelli@gmail.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Abbott Liu <liuwenliang@huawei.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Russell King <linux@armlinux.org.uk>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/5 v15] KASan for Arm
Date: Tue, 13 Oct 2020 10:57:15 -0700	[thread overview]
Message-ID: <10b1b6cd-3622-6c83-bd44-51ed906f2b6e@gmail.com> (raw)
In-Reply-To: <CAMj1kXEu_OUMYy+=LQ1Wm3yNm34qNSgKPHKiRmGxcWsz8z=OtA@mail.gmail.com>

On 10/12/20 11:34 PM, Ard Biesheuvel wrote:
> On Tue, 13 Oct 2020 at 05:22, Florian Fainelli <f.fainelli@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@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.
--
Florian

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