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

Message-ID: <e1f7cca54843abcef0c2703a5f7071c045b99baa.camel@alliedtelesis.co.nz>
Date:   Wed, 27 Nov 2019 08:20:12 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "stefan@...er.ch" <stefan@...er.ch>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "nico@...xnic.net" <nico@...xnic.net>,
        "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "natechancellor@...il.com" <natechancellor@...il.com>
CC:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Hamish Martin <Hamish.Martin@...iedtelesis.co.nz>
Subject: ARM expections for location of kernel, ramdisk and dtb

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?

Thanks,
Chris