Re: [PATCH 1/2] lib: add fast lzo decompressor

[Andreas Robinson <andr345@gmail.com>]

On Thu, 2009-04-02 at 10:30 -0400, John Stoffel wrote:
> >>>>> "Andreas" == Andreas Robinson <andr345@gmail.com> writes:
> 
> Andreas> On Wed, 2009-04-01 at 09:12 -0700, H. Peter Anvin wrote:
> >> OK, I'm more than a bit nervous about that, especially since we're
> >> trying to make the decompression functions more generic.
> 
> Andreas> Perhaps the system can default to the safe decompressor for
> Andreas> normal use and choose the fast one if STATIC is defined or
> Andreas> when system_state == SYSTEM_BOOTING?
> 
> So how do you prove that data is trusted?

The kernel and initramfs images are implicitly trusted, but that is not
unique to this implementation. None of the decompressors check the data
e.g by comparing checksums, AFAICT.

> What happens on buffer overflow?

The overflow is detected and an error is returned to the caller ... or
the kernel just committed suicide by overwriting itself. *cough*.

Ok, I will put back the checks that actually prevents output overruns.
It is still faster, but could no longer crash the system directly.

There would remain a 3-byte overflow at the end of the output buffer, by
design. However, it can be managed to never be a problem.

>   I don't think that a 20% speedup on decompression, with a
> possibility of borking the boot completely is worth it.  Or are you
> suggesting that people pre-test their initramfs images with this
> compressor before deciding to boot from it?

The compressor (lzop) has been around for a long while so it's probably
ok.

In case I broke the decompressor the best I can offer is more testing.
In its present form it unpacks a 5 MB initramfs without errors. Does it
need to be tested with more data? In that case, do you have any
suggestions?

Thanks,
Andreas