linux-kernel - Re: Status of bzip2 and lzma kernel compression for ARM?

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]

Date:	Fri, 3 Jul 2009 17:43:27 +0200
From:	Albin Tonnerre <albin.tonnerre@...e-electrons.com>
To:	Mike Rapoport <mike@...pulab.co.il>
Cc:	Alain Knaff <alain@...ff.lu>,
	Michael Opdenacker <michael-lists@...e-electrons.com>,
	Florian Fainelli <florian@...nwrt.org>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-embedded mailing list <linux-embedded@...r.kernel.org>
Subject: Re: Status of bzip2 and lzma kernel compression for ARM?

On Mon, Jun 29, 2009 at 03:21:45PM +0300, Mike Rapoport wrote :
> 
> 
> Alain Knaff wrote:
> > Alain Knaff wrote:
> >> Attached is a version of the ARM patch for 2.6.30
> >>
> >> There seems to be some issues with the include files (which did not pose
> >> any problems in 2.6.28...), but hopefully somebody more experienced with
> >> the ARM architecture (and with its recent development) than I can help
> >> out there.
> >>
> >> Regards,
> >>
> >> Alain
> > 
> > Actually, the needed changes turned out to be easier than I initially
> > feared. Attached a version that compiles all right.
> 
> I gave it a quick test and it hangs before "Decompressing kernel" is output.
> I hope I'll have time this week to debug what's wrong there.

On my testing board, it hangs after "Decompressing kernel" is output. It seems
that it's getting stuck in the following piece of code in lib/decompressor_lzma.c

while (get_pos(&wr) < header.dst_size) {
                int pos_state = get_pos(&wr) & pos_state_mask;
                uint16_t *prob = p + LZMA_IS_MATCH +
                        (cst.state << LZMA_NUM_POS_BITS_MAX) + pos_state;
                if (rc_is_bit_0(&rc, prob))
                        process_bit0(&wr, &rc, &cst, p, pos_state, prob,
                                     lc, literal_pos_mask);
                else {
                        process_bit1(&wr, &rc, &cst, p, pos_state, prob);
                        if (cst.rep0 == 0)
                                break;
                }
}

Based on some quick tests, it seems that header.dst_size is 0xFFFFFFFFFFFFFFFF,
and if my understanding is correct, it's because LZMA doesn't write the file
size in the header if it reads its input from a pipe, and piggy.lzma turns out
to be created using a pipe.

Replacing cmd_lzma in scripts/Makefile.lib by the following snippet:

cmd_lzma = (lzma -9 -c $(filter-out FORCE, $^) > $@ && $(call size_append, $(filter-out FORCE,$^)) >> $@ ) || (rm -f $@ ; false)

does the trick, as lzma is able to write the file size in the header (and I
think the second part is useless, as it's the filesize encoded in 32bits
little-endian). However, it now hangs right after the 'done, booting the
kernel.'

Hope that helps,
-- 
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/