linux-kernel - Re: [RESEND PATCH] mips: ralink: allow zboot

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 21 Mar 2019 18:29:09 -0600
From:   George Hilliard <thirtythreeforty@...il.com>
To:     Paul Burton <paul.burton@...s.com>
Cc:     Aaro Koskinen <aaro.koskinen@....fi>,
        "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH] mips: ralink: allow zboot

On Thu, Mar 21, 2019 at 5:40 PM Paul Burton <paul.burton@...s.com> wrote:
> On Thu, Mar 21, 2019 at 05:10:38PM -0600, George Hilliard wrote:
> > My version of U-Boot complains if I compile out LZMA support:
> > ---
> > => tftpboot 0x81000000 uImage; tftpboot 0x84000000 hawkeye.dtb; bootm
> > 0x81000000 - 0x84000000
> > (snip)
> > Bytes transferred = 7349 (1cb5 hex)
> > ## Booting kernel from Legacy Image at 81000000 ...
> >    Image Name:   Linux-5.1.0-rc1
> >    Image Type:   MIPS Linux Kernel Image (lzma compressed)
> >    Data Size:    1465871 Bytes = 1.4 MiB
> >    Load Address: 80000000
> >    Entry Point:  80344338
> >    Verifying Checksum ... OK
> > ## Flattened Device Tree blob at 84000000
> >    Booting using the fdt blob at 0x84000000
> >    Uncompressing Kernel Image ... Unimplemented compression type 3
> > exit not allowed from main input shell.
> > =>
> > ---
>
> There you're using a uImage though, which is different to
> CONFIG_SYS_SUPPORTS_ZBOOT. Even without CONFIG_SYS_SUPPORTS_ZBOOT
> enabled, you can build either a compressed or uncompressed uImage.
>
> Some platforms enable one of those targets by default but it doesn't
> appear that ralink does, so I guess you're specifying a uImage.lzma
> target when building the kernel? Try doing that when
> CONFIG_SYS_SUPPORTS_ZBOOT isn't enabled - it'll still generate the same
> type of LZMA-compressed uImage.

OK, Buildroot was obfuscating this a little from me.  I selected its LZMA
compression option, and nothing happened.  Asking for LZMA does not make it
build uImage.lzma.  Selecting the *kernel's* KERNEL_LZMA option caused
Buildroot's `make uImage` to make the same sort of image as made by
`make uImage.lzma` as you suggest, for a reason I have not figured out.

> What CONFIG_SYS_SUPPORTS_ZBOOT does is produce a program (vmlinuz) which
> contains a compressed version of vmlinux.bin along with some code to
> decompress it. The decompression is performed by vmlinuz itself, not by
> U-Boot.

OK, that makes more sense.  I have not tested zboot then :)

> Now it could still be valid to select CONFIG_SYS_SUPPORTS_ZBOOT if you
> had a need for a better compression algorithm & couldn't update your
> bootloader to support it, but that would be solving a different problem
> than your commit message claims & it wouldn't matter at all whether the
> bootloader supports a particular compression algorithm.

Yeah, I agree.  I will just make a uImage.lzma, which is what I was after
anyway.

Thank you very much for the explanation!

George