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

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]

Message-Id: <1238752196.8118.185.camel@andreas-desktop>
Date:	Fri, 03 Apr 2009 11:49:56 +0200
From:	Andreas Robinson <andr345@...il.com>
To:	John Stoffel <john@...ffel.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Alain Knaff <alain@...ff.lu>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] lib: add fast lzo decompressor

On Thu, 2009-04-02 at 10:30 -0400, John Stoffel wrote:
> >>>>> "Andreas" == Andreas Robinson <andr345@...il.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

--
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/