linux-kernel - Re: ARM expections for location of kernel, ramdisk and dtb

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: <c108d58e3ee511040bb99edb28c893b27b238bdb.camel@alliedtelesis.co.nz>
Date:   Wed, 27 Nov 2019 22:15:57 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     "linux@...linux.org.uk" <linux@...linux.org.uk>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        "stefan@...er.ch" <stefan@...er.ch>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "nico@...xnic.net" <nico@...xnic.net>,
        "natechancellor@...il.com" <natechancellor@...il.com>,
        Hamish Martin <Hamish.Martin@...iedtelesis.co.nz>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: ARM expections for location of kernel, ramdisk and dtb

Hi Russell,

On Wed, 2019-11-27 at 09:26 +0000, Russell King - ARM Linux admin
wrote:
> On Wed, Nov 27, 2019 at 08:20:12AM +0000, Chris Packham wrote:
> > Hi All,
> > 
> > We're updating our systems to use the latest kernel. For many of them
> > this is a fairly large leap. One problem we've hit is that durng boot
> > the dtb is clobbered by the uncompressed kernel.
> > 
> > Here's a snippet of output from u-boot
> > 
> > ## Loading kernel from FIT Image at 62000000 ...
> >    Using 'XS916MXS@2' configuration
> >    Trying 'kernel@1' kernel subimage
> >      Description:  linux
> >      Created:      2019-11-27   6:53:48 UTC
> >      Type:         Kernel Image
> >      Compression:  uncompressed
> >      Data Start:   0x62000174
> >      Data Size:    3495432 Bytes = 3.3 MiB
> >      Architecture: ARM
> >      OS:           Linux
> >      Load Address: 0x00800000
> >      Entry Point:  0x60800000
> >    ...
> >    Booting using the fdt blob at 0x63b90f6c
> >    Loading Kernel Image ... OK
> >    Loading Ramdisk to 6e7c6000, end 70000000 ... OK
> >    Loading Device Tree to 607fb000, end 607fffd8 ... OK
> > 
> > Starting kernel ...
> > 
> > Uncompressing Linux... done, booting the kernel.
> > 
> > Error: invalid dtb and unrecognized/unsupported machine ID
> >   r1=0x0000206e, r2=0x00000000
> > 
> > Between old and new the location of the devicetree hasn't actually
> > changed. But what has changed is the size of the kernel the self
> > extracting kernel unpacks to 0x60008000 and with our current
> > configuration extends into where the dtb is located.
> > 
> > Documentation/arm/booting.rst says that "The dtb must be placed in a
> > region of memory where the kernel decompressor will not overwrite it". 
> > 
> > This suggests that the problem is with our u-boot configuration, but
> > how is u-boot supposed to know where the self-extracting kernel is
> > going to place things? As far as I can tell u-boot is doing a
> > reasonable job of finding a place to put the dtb which it thinks is
> > unused. I'm not sure why it's picked 0x607fb000 instead of putting it
> > just under the ramdisk but regardless with the information u-boot has
> > that address is up for grabs.
> > 
> > Has this come up before? The self-extraction code is fairly careful not
> > to overwrite itself but doesn't seem to pay any attention to the dtb
> > which surprised me. So I wonder if I'm missing something?
> 
> The self-extraction hasn't changed much over the years, and basically
> follows the same method which has worked for the vast majority of
> platforms.
> 
> Where things fall down is where things are placed too close, and yes,
> as the kernel grows, what was reasonable years ago becomes too close
> with modern kernels.
> 
> The problem has been compounded by the various different compression
> algorithms that can now be used for the compressed kernel.
> 

I don't think it's that we don't know how big the extracted kernel will
be. It's just that we aren't doing anything with that information w.r.t
the dtb.

> kexec also ran into this problem, and there is now enough information
> in a modern kernel to calculate how much space the decompressor is
> going to require.  Have a look at the current kexec sources for how
> it is done.
> 

Thanks will do. If we get something suitable we'll post a patch.