kexec failures with DEBUG_RODATA

[Russell King - ARM Linux]

On Wed, Jun 15, 2016 at 03:20:05PM -0700, Kees Cook wrote:
> On Wed, Jun 15, 2016 at 2:13 PM, Russell King - ARM Linux
> <linux at armlinux.org.uk> wrote:
> > On Tue, Jun 14, 2016 at 11:05:23AM -0700, Kees Cook wrote:
> >> I'm much less familiar with the ARM decompression stub, but is there a
> >> boot image header (like x86 has)? If not, perhaps we can invent one,
> >> and it can carry all the details needed for a bootloader to do the
> >> right things.
> >
> > With a bit of tinkering around, I now have this:
> >
> > 00000000 <.data>:
> >        0:       e1a00000        nop                     ; (mov r0, r0)
> >        4:       e1a00000        nop                     ; (mov r0, r0)
> >        8:       e1a00000        nop                     ; (mov r0, r0)
> >        c:       e1a00000        nop                     ; (mov r0, r0)
> >       10:       e1a00000        nop                     ; (mov r0, r0)
> >       14:       e1a00000        nop                     ; (mov r0, r0)
> >       18:       e1a00000        nop                     ; (mov r0, r0)
> >       1c:       e1a00000        nop                     ; (mov r0, r0)
> >       20:       ea00000f        b       0x64
> >
> > Then follows the existing "header" which we've had there for years:
> >
> >       24:       016f2818        ; LE magic number
> >       28:       00000000        ; LE zImage start address (always zero now)
> >       2c:       00431fe0        ; LE zImage _edata
> >       30:       04030201        ; endian flag
> >
> > And now comes the new header:
> >
> >       34:       016f2818        ; LE magic number
> 
> Should this be a different magic from the existing header's magic?

What use would a different number be?  It's not something you scan for,
because this block is always at 0x24 bytes into the zImage for a binary
zImage.

> >       38:       00000001        ; LE version number (v1)
> 
> Should a "size" follow the version number instead of the explicit 64
> bytes of zeros?

I don't see the use of a size field.  If we have a size field, then
we need to validate the version number (which tells us the format of
the data) against the size, and it all gets really messy - what if
we have a version number which indicates that we have more data than
the size field indicates?

> >       3c:       01287000        ; LE total space required for decompressor
> >       40:       00e54000        ; LE uncompressed image size
> >
> > Up to 64 bytes available here for future expansion, currently filled
> > with zeros.
> >         ...
> >
> > Remainder of the zImage code:
> >       64:       e10f9000        mrs     r9, CPSR
> >
> > I'm rather on the fence whether we need to give the uncompressed image
> > size - the important thing is the size of memory that's required for
> > the decompressor to run, which is sizeof(uncompressed kernel) rounded
> > up to 256 bytes, and the relocated decompressor image size.
> 
> I think it's important information since it allows a boot loader to
> figure out if there's room in a given range for the result. While
> there's no relocation support yet, if we gain it on ARM and we want to
> support KASLR, it will be very handy to have the uncompressed size
> available.

It's really not useful for that purpose.  The size of the uncompressed
image doesn't tell you that you can touch the next few bytes after the
image.  In fact, you can't, because that's where the decompressor
potentially relocates itself to.

The one which is of importance to the boot environment layout is the
"total space required for decompressor", which is the one which must
be respected.

In fact, the apparent confusion over this reinforces my belief that we
should _not_ give the size of the uncompressed image at all.

The boot environment must be setup such that there is room for the
uncompressed image (aligned currently to 256 bytes) followed by the
size of the compressed image, with any appended DTBs included.
Anything which is located below that is likely to get trampled by
the decompressor.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.