linux-kernel - Re: [PATCH 04/12] mips: Reserve memory for the kernel image resources

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: <alpine.LFD.2.21.2010140244560.866917@eddie.linux-mips.org>
Date:   Wed, 14 Oct 2020 10:49:05 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     Serge Semin <fancer.lancer@...il.com>
cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Paul Burton <paul.burton@...s.com>,
        James Hogan <jhogan@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Bogendoerfer <tbogendoerfer@...e.de>,
        Huacai Chen <chenhc@...ote.com>,
        Stefan Agner <stefan@...er.ch>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Juergen Gross <jgross@...e.com>, linux-mips@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Atsushi Nemoto <anemo@....ocn.ne.jp>
Subject: Re: [PATCH 04/12] mips: Reserve memory for the kernel image
 resources

On Wed, 22 May 2019, Serge Semin wrote:

> > > The problem might be fixed there by the next patch:
> > > ---
> > > diff --git a/arch/mips/dec/prom/memory.c b/arch/mips/dec/prom/memory.c
> > > index 5073d2ed78bb..5a0c734b5d04 100644
> > > --- a/arch/mips/dec/prom/memory.c
> > > +++ b/arch/mips/dec/prom/memory.c
> > > @@ -91,29 +91,14 @@ void __init prom_meminit(u32 magic)
> > >                 pmax_setup_memory_region();
> > >         else
> > >                 rex_setup_memory_region();
> > > -}
> > > -
> > > -void __init prom_free_prom_memory(void)
> > > -{
> > > -       unsigned long end;
> > > -
> > > -       /*
> > > -        * Free everything below the kernel itself but leave
> > > -        * the first page reserved for the exception handlers.
> > > -        */
> > >
> > >  #if IS_ENABLED(CONFIG_DECLANCE)
> > >         /*
> > > -        * Leave 128 KB reserved for Lance memory for
> > > -        * IOASIC DECstations.
> > > +        * Reserve 128 KB for Lance memory for IOASIC DECstations.
> > >          *
> > >          * XXX: save this address for use in dec_lance.c?
> > >          */
> > >         if (IOASIC)
> > > -               end = __pa(&_text) - 0x00020000;
> > > -       else
> > > +               memblock_reserve(__pa_symbol(&_text), 0x00020000);
> > 
> > Shouldn't that be
> > 
> >     memblock_reserve(__pa_symbol(&_text) - 0x00020000, 0x00020000);
> > 
> > ?
> > 
> 
> Right. Thanks. The updated version of the patch is attached to this email.
> 
> -Sergey
> 
> > >  #endif
> > > -               end = __pa(&_text);
> > > -
> > > -       free_init_pages("unused PROM memory", PAGE_SIZE, end);
> > >  }
> > > ---
> > >
> > > Didn't wanna use prom_FREE_prom_memory to actually reserve a memory
> > > chunk, so I moved the reservation into the prom_meminit() method.
> > 
> > I guess Maciej will test this on real hardware, eventually...

 I finally got to it as I was hit by it the hard way (and I do have kept 
the thread in my inbox!), however this is the wrong fix.

 With DEC hardware the whole 128KiB region is reserved as firmware working 
memory area and we call into the firmware throughout bootstrap on several 
occasions.  Therefore we have to stay away from it until we know we won't 
need any firmware services any longer, which is at this point.  So this 
piece has to stay, and the removed reservation has to be reinstated in 
platform code.  I'll be posting a fix separately.

 NB I suspect CFE platforms may need a similar fix, but I don't have 
access to my SWARM now, so I'll verify it on another occasion.

 Other platforms may need it too; at least up to a point an assumption was 
the kernel load address is just at the end of any firmware working area 
typically allocated right beyond the exception vector area, hence the 
reservation.  I realise the assumption may have changed at one point and 
the oldtimers who have known it may have been away or not paying enough 
attention while the newcomers did not realise that.

  Maciej