linux-kernel - Re: [PATCH] arm64: Track no early_pgtable

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]

Date:   Fri, 5 Nov 2021 13:05:58 +0200
From:   Mike Rapoport <rppt@...nel.org>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     Qian Cai <quic_qiancai@...cinc.com>, Will Deacon <will@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-arm-kernel@...ts.infradead.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: Track no early_pgtable_alloc() for kmemleak

On Fri, Nov 05, 2021 at 10:08:05AM +0000, Catalin Marinas wrote:
> On Thu, Nov 04, 2021 at 01:57:03PM -0400, Qian Cai wrote:
> > On 11/4/21 1:06 PM, Mike Rapoport wrote:
> > > I think I'll be better to rename MEMBLOCK_ALLOC_KASAN to, say,
> > > MEMBLOCK_ALLOC_NOKMEMLEAK and use that for both KASAN and page table cases.
> > 
> > Okay, that would look a bit nicer.
> 
> Or MEMBLOCK_ALLOC_ACCESSIBLE_NOLEAKTRACE to match SLAB_NOLEAKTRACE and
> also hint that it's accessible memory.

Hmm, I think MEMBLOCK_ALLOC_NOLEAKTRACE is enough. Having a constant
instead of end limit already implies there is no limit and when we update
the API to use lower bits or a dedicated 'flags' we won't need to change
the flag name as well.

> > > But more generally, we are going to hit this again and again.
> > > Couldn't we add a memblock allocation as a mean to get more memory to
> > > kmemleak::mem_pool_alloc()?
> > 
> > For the last 5 years, this is the second time I am ware of this kind of
> > issue just because of the 64KB->4KB switch on those servers, although I
> > agree it could happen again in the future due to some new debugging
> > features etc. I don't feel a strong need to rewrite it now though. Not
> > sure if Catalin saw things differently. Anyway, Mike, do you agree that
> > we could rewrite that separately in the future?
> 
> I was talking to Mike on IRC last night and I think you still need a
> flag, otherwise you could get a recursive memblock -> kmemleak ->
> memblock call (that's why we have SLAB_NOLEAKTRACE). So for the time
> being, a new MEMBLOCK_* definition would do.
> 
> I wonder whether we could actually use the bottom bits in the end/limit
> as actual flags so one can do (MEMBLOCK_ALLOC_ACCESSIBLE |
> MEMBLOCK_NOLEAKTRACE). But that could be for a separate clean-up.

We never restricted end/limit to be on a word boundary, but I doubt that in
practice we'd ever have the low bits set.

I'm not entirely happy with using end limit parameter for this, I'd like to
see how much churn it will be to extend some of memblock_*_alloc with an
explicit flags parameter.

--
Sincerely yours,
Mike.