linux-kernel - Re: [tip: x86/urgent] x86/setup: Call early_reserve

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]

Message-ID: <YUhYkKDe364BGb2f@linux.ibm.com>
Date:   Mon, 20 Sep 2021 12:46:56 +0300
From:   Mike Rapoport <rppt@...ux.ibm.com>
To:     Juergen Gross <jgross@...e.com>
Cc:     Borislav Petkov <bp@...en8.de>, Mike Galbraith <efault@....de>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org,
        marmarek@...isiblethingslab.com, Borislav Petkov <bp@...e.de>,
        stable@...r.kernel.org, x86@...nel.org
Subject: Re: [tip: x86/urgent] x86/setup: Call early_reserve_memory() earlier

Hi,

On Mon, Sep 20, 2021 at 08:00:31AM +0200, Juergen Gross wrote:
> On 19.09.21 19:15, Borislav Petkov wrote:
> > On Sun, Sep 19, 2021 at 06:55:16PM +0200, Mike Galbraith wrote:
> > > On Thu, 2021-09-16 at 10:50 +0000, tip-bot2 for Juergen Gross wrote:
> > > > The following commit has been merged into the x86/urgent branch of
> > > > tip:
> > > > 
> > > > x86/setup: Call early_reserve_memory() earlier
> > > 
> > > This commit rendered tip toxic to my i4790 desktop box and i5-6200U
> > > lappy.  Boot for both is instantly over without so much as a twitch.
> > > 
> > > Post bisect revert made both all better.
> > 
> > I had a suspicion that moving stuff around like that would not just
> > simply work in all cases, as our boot order is very lovely and fragile.
> > 
> > And it booted just fine on my machines here.
> > 
> > ;-\
> > 
> > Anyway, commit zapped from the x86/urgent lineup. We'll have to have a
> > third try later.
> > 
> 
> How will that try look like? I'm seeing the following alternatives:
> 
> 1. Just revert a799c2bd29d19c565 ("x86/setup: Consolidate early memory
>    reservations").
> 
> 2. Try to move the call of early_reserve_memory() just before the call
>    of e820__memory_setup().
> 
> 3. Split early_reserve_memory() into two parts, with the first part
>    doing the memblock_reserve() calls for the kernel text, initrd and
>    page 0 right at the start of setup_arch(), and the second part for
>    the rest at the same place it is handled now.
> 
> 4. Analyze why Mike's systems fail to boot and try to fix his issue(s)
>    (probably via one of the above ways).
> 
> Looking at the calls done in early_reserve_memory() I have my doubts
> that memblock_x86_reserve_range_setup_data() will work before
> early_ioremap_init() has been called, as it is using early_memremap().
> This would suggest variant 2 could be a working solution.
> 
> In case I'm wrong with my doubts I'd prefer variant 3.

I actually prefer variant 2 to keep the early memory reservations together
as much as possible. 

I tend to agree with your doubts about
memblock_x86_reserve_range_setup_data(), but it should be fine to move
early_reserve_memory() just before e820__memory_setup().
  
Anyway, I'd like to understand why Mike's systems fail before moving on
with the fixes.

-- 
Sincerely yours,
Mike.