linux-kernel - Re: [PATCH 0/2] x86/setup: consolidate early memory reservations

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210115115614.GB19300@MiWiFi-R3L-srv>
Date:   Fri, 15 Jan 2021 19:56:14 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Mike Rapoport <rppt@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        David Hildenbrand <david@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Mel Gorman <mgorman@...e.de>, Michal Hocko <mhocko@...nel.org>,
        Mike Rapoport <rppt@...ux.ibm.com>, Qian Cai <cai@....pw>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vlastimil Babka <vbabka@...e.cz>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, x86@...nel.org
Subject: Re: [PATCH 0/2] x86/setup: consolidate early memory reservations

On 01/15/21 at 07:42pm, Baoquan He wrote:
> On 01/15/21 at 10:32am, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@...ux.ibm.com>
> > 
> > Hi,
> > 
> > David noticed that we do some of memblock_reserve() calls after allocations
> > are possible:
> > 
> > https://lore.kernel.org/lkml/6ba6bde3-1520-5cd0-f987-32d543f0b79f@redhat.com
> 
> Thanks for CC-ing me, so I think the above patch from Roman is dangerous.
> KASLR does put kernel randomly in a place, but we did a brutal parse to
> get SRAT table so that we know where is hotpluggable area during boot
> decompression stage. In kernel, at the beginning, we don't know that
> before ACPI init. Roman's patch is wrong if I don't miss something.

Sorry, I was wrong. Bottom up searching disregarding kernel end is
good optimization. Please ignore this noise.

> 
> I will add comment in that thread.
> 
> Thanks
> Baoquan
> 
> > 
> > For now there is no actual problem because in top-down mode we allocate
> > from the end of the memory and in bottom-up mode we allocate above the
> > kernel image. But there is a patch in the mm tree that allow bottom-up
> > allocations below the kernel:
> > 
> > https://lore.kernel.org/lkml/20201217201214.3414100-2-guro@fb.com
> > 
> > and with this change we may get a memory corruption if an allocation steps
> > on some of the firmware areas that are yet to be reserved.
> > 
> > The below patches consolidate early memory reservations done during
> > setup_arch() so that memory used by firmware, bootloader, kernel text/data
> > and the memory that should be excluded from the available memory for
> > whatever other reason is reserved before memblock allocations are possible.
> > 
> > The patches are vs v5.11-rc3-mmots-2021-01-12-02-00 as I think they are
> > prerequisite for the memblock bottom-up changes, but if needed I can rebase
> > then on another tree.
> > 
> > Mike Rapoport (2):
> >   x86/setup: consolidate early memory reservations
> >   x86/setup: merge several reservations of start of the memory
> > 
> >  arch/x86/kernel/setup.c | 85 +++++++++++++++++++++--------------------
> >  1 file changed, 43 insertions(+), 42 deletions(-)
> > 
> > -- 
> > 2.28.0
> >