linux-kernel - Re: [PATCH v1] Revert "mm: kmemleak: alloc gray object for reserved region with direct map"

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:   Thu, 26 Jan 2023 16:54:07 -0800
From:   Isaac Manjarres <isaacmanjarres@...gle.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Frank Rowand <frowand.list@...il.com>, linux-mm@...ck.org,
        Saravana Kannan <saravanak@...gle.com>, stable@....kernel.org,
        Calvin Zhang <calvinzhang.cool@...il.com>,
        kernel-team@...roid.com, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] Revert "mm: kmemleak: alloc gray object for reserved
 region with direct map"

On Wed, Jan 25, 2023 at 03:02:15PM -0600, Rob Herring wrote:
> On Tue, Jan 24, 2023 at 03:02:54PM -0800, Isaac J. Manjarres wrote:
> > This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769.
> > 
> > Kmemleak operates by periodically scanning memory regions for pointers
> > to allocated memory blocks to determine if they are leaked or not.
> > However, reserved memory regions can be used for DMA transactions
> > between a device and a CPU, and thus, wouldn't contain pointers to
> > allocated memory blocks, making them inappropriate for kmemleak to
> > scan. Thus, revert this commit.
> 
> Both commits talk about the same type of memory as CMA is used for DMA. 
> Neither commit tells me what are the implications of kmemleak scanning 
> or not scanning the region? Are there false positives?
If kmemleak scans the region when CONFIG_DEBUG_PAGEALLOC is enabled,
and the CMA region is not in use, then kmemleak will cause a page-fault,
because the region is unmapped from the kernel's address space. kmemleak
scans the region because it thinks it is in use/allocated, when it's
not. While this sounds like a problem of kmemleak not being informed
about the region not being actually allocated, it's also a matter of CMA
regions not being suitable for kmemleak to scan in the first place,
because they don't have pointers to other memory blocks; they might have
data from DMA transactions with another device, so it doesn't make
sense for kmemleak to scan these areas.

--Isaac