linux-kernel - Re: [PATCH] powerpc/kvm: silence kmemleak false positives

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:   Mon, 11 May 2020 07:43:30 -0400
From:   Qian Cai <cai@....pw>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     paulus@...abs.org, benh@...nel.crashing.org,
        catalin.marinas@....com, kvm-ppc@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] powerpc/kvm: silence kmemleak false positives

> On May 11, 2020, at 7:15 AM, Michael Ellerman <mpe@...erman.id.au> wrote:
> 
> There is kmemleak_alloc_phys(), which according to the docs can be used
> for tracking a phys address.
> 
> Did you try that?

Caitlin, feel free to give your thoughts here.

My understanding is that it seems the doc is a bit misleading. kmemleak_alloc_phys() is to allocate kmemleak objects for a physical address range, so  kmemleak could scan those memory pointers within for possible referencing other memory. It was only used in memblock so far, but those new memory allocations here contain no reference to other memory.

In this case, we have already had kmemleak objects for those memory allocation. It is just that other pointers reference those memory by their physical address which is a known kmemleak limitation won’t be able to track the the connection. Thus, we always use kmemleak_ignore() to not reporting those as leaks and don’t scan those because they do not contain other memory reference.