[PATCH 0/5 v15] KASan for Arm

[Florian Fainelli]

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