linux-kernel - Re: [PATCH] mm, page_alloc: check pfn is valid before moving to freelist

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

Message-ID: <Yl5ap4veIr5ugce1@linux.ibm.com>
Date:   Tue, 19 Apr 2022 09:45:59 +0300
From:   Mike Rapoport <rppt@...ux.ibm.com>
To:     Sudarshan Rajagopalan <quic_sudaraja@...cinc.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Anshuman Khandual <anshuman.khandual@....com>,
        Suren Baghdasaryan <surenb@...gle.com>
Subject: Re: [PATCH] mm, page_alloc: check pfn is valid before moving to
 freelist

On Mon, Apr 18, 2022 at 03:32:21PM -0700, Sudarshan Rajagopalan wrote:
> On 4/18/2022 12:24 AM, Mike Rapoport wrote:
> > On Fri, Apr 15, 2022 at 02:30:52AM +0530, Sudarshan Rajagopalan wrote:
> > > On 4/14/2022 2:18 AM, Mike Rapoport wrote:
> > >
> > > We have a feature where we carve out some portion of memory in RAM partition
> > > table, hence we see such base addresses here.
> > >
> > Cannot the firmware align that portion at some sensible boundary?
> > Or at least report the carved out range as "reserved" (and maybe NOMAP)
> > rather than as hole?
> 
> We can have the firmware or ABL align the address to next pageblock size
> boundary. This would simple mean loosing few MBs of memory with alignment.
> Same with making them as "reserved" with "nomap".

Reserved and nomap do not have to be aligned and there will be a valid
struct page for such regions.

Still, the kernel should be able to cope with firmware oddities so a fix
for 5.15 is still needed.
 
> > That said, your patch will not fix anything in the current kernel because
> > the issue should not happen there, right?
> 
> Yes, the issue seems to be fixed in latest kernel version with the patches
> to drop arm64 pfn_valid. But the core issue is present on previous kernel
> versions with the scenario explained. Any procedure to have this fixed on
> 5.15 kernel?
>
> > I'd suggest backporting a9c38c5d267c ("dma-mapping: remove bogus test for
> > pfn_valid from dma_map_resource") and 3de360c3fdb3 ("arm64/mm: drop
> > HAVE_ARCH_PFN_VALID") to 5.15.
>
> The issue is not seen with these patches backported. Not sure of the
> procedure to send patches for 5.15 kernel, but can we have them backported
> to 5.15?

Please look at Documentation/process/stable-kernel-rules.rst for
explanation how to send patches to stable kernels. 

-- 
Sincerely yours,
Mike.