linux-kernel - Re: [PATCH] memblock: exclude NOMAP regions from kmemleak

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 19 Oct 2021 12:37:10 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     Mike Rapoport <rppt@...nel.org>
Cc:     Qian Cai <quic_qiancai@...cinc.com>, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
        linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] memblock: exclude NOMAP regions from kmemleak

On Tue, Oct 19, 2021 at 08:45:49AM +0300, Mike Rapoport wrote:
> On Mon, Oct 18, 2021 at 11:55:40PM -0400, Qian Cai wrote:
> > On 10/13/2021 1:47 AM, Mike Rapoport wrote:
> > > From: Mike Rapoport <rppt@...ux.ibm.com>
> > > 
> > > Vladimir Zapolskiy reports:
> > > 
> > > commit a7259df76702 ("memblock: make memblock_find_in_range method private")
> > > invokes a kernel panic while running kmemleak on OF platforms with nomaped
> > > regions:
> > > 
> > >   Unable to handle kernel paging request at virtual address fff000021e00000
> > >   [...]
> > >     scan_block+0x64/0x170
> > >     scan_gray_list+0xe8/0x17c
> > >     kmemleak_scan+0x270/0x514
> > >     kmemleak_write+0x34c/0x4ac
> > > 
> > > Indeed, NOMAP regions don't have linear map entries so an attempt to scan
> > > these areas would fault.
> > > 
> > > Prevent such faults by excluding NOMAP regions from kmemleak.
> > > 
> > > Link: https://lore.kernel.org/all/8ade5174-b143-d621-8c8e-dc6a1898c6fb@linaro.org
> > > Fixes: a7259df76702 ("memblock: make memblock_find_in_range method private")
> > > Signed-off-by: Mike Rapoport <rppt@...ux.ibm.com>
> > > Tested-by: Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>
> > 
> > Mike, reverting this commit on the top of today's linux-next fixed the early booting hang
> > on an arm64 server with kmemleak. Even with "earlycon", it could only print out those
> > lines.
> > 
> > EFI stub: Booting Linux Kernel...
> > EFI stub: EFI_RNG_PROTOCOL unavailable
> > EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 128k boundary
> > EFI stub: ERROR: FIRMWARE BUG: Image BSS overlaps adjacent EFI memory region
> > EFI stub: Using DTB from configuration table
> > EFI stub: Exiting boot services…
> > 
> > I could help to confirm if it hangs right in the early boot somewhere if needed.
> 
> The kernel config and a log of working kernel would help to start with.

I don't think there's much in the log other than the EFI stub above.

> > start_kernel()
> >   setup_arch()
> >     paging_init()
> >       map_mem()
> >         memblock_mark_nomap(

Is this actual trace? It would be good to know where exactly it got
stuck.

> So we have kmemleak_free_part_phys() here.

I wonder whether the memblock_mark_nomap() here is too early for
kmemleak. We don't have the linear map created, though it shouldn't be
an issue as the kernel sections are mapped. Also I think
delete_object_part() in kmemleak.c would bail out early as there
shouldn't be any prior memblock_alloc for this range.

-- 
Catalin