linux-kernel - Re: [PATCH v1 0/2] Fixes for kmemleak tracking with CMA regions

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] [day] [month] [year] [list]

Message-ID: <Y9M5eYzJcFbwlC9g@google.com>
Date:   Thu, 26 Jan 2023 18:39:53 -0800
From:   Isaac Manjarres <isaacmanjarres@...gle.com>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Saravana Kannan <saravanak@...gle.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        kernel-team@...roid.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Mike Rapoport <rppt@...nel.org>
Subject: Re: [PATCH v1 0/2] Fixes for kmemleak tracking with CMA regions

On Wed, Jan 25, 2023 at 12:08:58PM +0000, Catalin Marinas wrote:
> That's an option. If there's too much churn to add a flag, an
> alternative is to use the bottom bit of 'end' to set the noleaktrace
> flag.
Using the least significant bit won't work; there are allocations for
CMA regions that can be specified to occur within the first 4 GB of
memory, and would have an alloc-ranges of [0 0xffff_ffff]. I also don't
think there's anything in the memblock documentation that ensures that
those bits are supposed to be clear all the time.

> Yet another idea is to avoid the kmemleak callback on all the 'phys'
> memblock allocations. We can add the callback to the higher level
> memblock_alloc() which returns a VA but the lower level 'phys' variants
> could simply avoid it. However, I think we still need the
> MEMBLOCK_ALLOC_NOLEAKTRACE flag for the kasan shadow allocation. Well,
> given that this flag is not widely used, we can add explicit
> kmemleak_ignore() calls in those four places.
> 
> I think the latter, if it works, would be the least intrusive.

I agree; I think using kmemleak_ignore() would be best. I will
split that into series: 1 series that fixes the kmemleak issue
with CMA regions by reverting Calvin's patch and adding a call
to kmemleak_ignore in the call-stack I referenced earlier, and
then another series that cleans up the usage of the flag.

--Isaac