coreboot-kgpe-d16/src/lib/lzma.c

55 lines
1.7 KiB
C
Raw Normal View History

/*
* coreboot interface to memory-saving variant of LZMA decoder
*
* Copyright (C) 2006 Carl-Daniel Hailfinger
* Released under the GNU GPL v2 or later
*
* Parts of this file are based on C/7zip/Compress/LZMA_C/LzmaTest.c from the LZMA
* SDK 4.42, which is written and distributed to public domain by Igor Pavlov.
*
*/
#include <console/console.h>
#include <string.h>
#include <lib.h>
#include "lzmadecode.h"
unsigned long ulzma(unsigned char * src, unsigned char * dst)
{
unsigned char properties[LZMA_PROPERTIES_SIZE];
UInt32 outSize;
SizeT inProcessed;
SizeT outProcessed;
int res;
CLzmaDecoderState state;
SizeT mallocneeds;
Add and consistently use wrapper macro for romstage static variables x86 systems run their romstage as execute-in-place from flash, which prevents them from having writable data segments. In several code pieces that get linked into both romstage and ramstage, this has been worked around by using a local variable and having the 'static' storage class guarded by #ifndef __PRE_RAM__. However, x86 is the only architecture using execute-in-place (for now), so it does not make sense to impose the restriction globally. Rather than fixing the #ifdef at every occurrence, this should really be wrapped in a way that makes it easier to modify in a single place. The chromeos/cros_vpd.c file already had a nice approach for a wrapper macro, but unfortunately restricted it to one file... this patch moves it to stddef.h and employs it consistently throughout coreboot. BRANCH=nyan BUG=None TEST=Measured boot time on Nyan_Big before and after, confirmed that it gained 6ms from caching the FMAP in vboot_loader.c. Original-Change-Id: Ia53b94ab9c6a303b979db7ff20b79e14bc51f9f8 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/203033 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit c8127e4ac9811517f6147cf019ba6a948cdaa4a5) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I44dacc10214351992b775aca52d6b776a74ee922 Reviewed-on: http://review.coreboot.org/8055 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-06-07 01:10:56 +02:00
MAYBE_STATIC unsigned char scratchpad[15980];
unsigned char *cp;
memcpy(properties, src, LZMA_PROPERTIES_SIZE);
/* The outSize in LZMA stream is a 64bit integer stored in little-endian
* (ref: lzma.cc@LZMACompress: put_64). To prevent accessing by
* unaligned memory address and to load in correct endianness, read each
* byte and re-construct. */
cp = src + LZMA_PROPERTIES_SIZE;
outSize = cp[3] << 24 | cp[2] << 16 | cp[1] << 8 | cp[0];
if (LzmaDecodeProperties(&state.Properties, properties, LZMA_PROPERTIES_SIZE) != LZMA_RESULT_OK) {
printk(BIOS_WARNING, "lzma: Incorrect stream properties.\n");
If you have option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 option CONFIG_PRECOMPRESSED_PAYLOAD=1 set in Config.lb but accidentally use an uncompressed payload, coreboot (v2) bombs out like this: elfboot: Attempting to load payload. rom_stream: 0xfffc0000 - 0xfffdefff Uncompressing to RAM 0x01000000 Decoder scratchpad too small! Decoding error = 1 Unexpected Exception: 6 @ 10:04000408 - Halting Code: 0 eflags: 00010057 eax: 00000101 ebx: 04000400 ecx: 000003d4 edx: fffc0000 edi: 04000400 esi: 04000401 ebp: 04000400 esp: 0013dfb4 The attached patch modifies v2's lzma code so that it assumes an uncompressed payload if it fails to find a properly compressed payload. Compare with the fatal error above: elfboot: Attempting to load payload. rom_stream: 0xfffc0000 - 0xfffdefff Uncompressing to RAM 0x01000000 Decoder scratchpad too small! olen = 0x00000000 done. Decompression failed. Assuming payload is uncompressed... Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 If you don't have CONFIG_COMPRESSED_PAYLOAD_LZMA and CONFIG_PRECOMPRESSED_PAYLOAD set and use an uncompressed payload, things are as before: elfboot: Attempting to load payload. rom_stream: 0xfffc0000 - 0xfffdefff Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 One can argue that this is a case of 'builder beware', but my counter argument is that anything that causes unexpected runtime breakage is really, really, really bad, and should be avoided where possible. This patch also fixes one erroneous comment. Signed-off-by: Ward Vandewege <ward@gnu.org> Acked-by: Myles Watson <mylesgw@gmail.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3542 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2008-08-27 23:53:11 +02:00
return 0;
}
mallocneeds = (LzmaGetNumProbs(&state.Properties) * sizeof(CProb));
if (mallocneeds > 15980) {
printk(BIOS_WARNING, "lzma: Decoder scratchpad too small!\n");
If you have option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 option CONFIG_PRECOMPRESSED_PAYLOAD=1 set in Config.lb but accidentally use an uncompressed payload, coreboot (v2) bombs out like this: elfboot: Attempting to load payload. rom_stream: 0xfffc0000 - 0xfffdefff Uncompressing to RAM 0x01000000 Decoder scratchpad too small! Decoding error = 1 Unexpected Exception: 6 @ 10:04000408 - Halting Code: 0 eflags: 00010057 eax: 00000101 ebx: 04000400 ecx: 000003d4 edx: fffc0000 edi: 04000400 esi: 04000401 ebp: 04000400 esp: 0013dfb4 The attached patch modifies v2's lzma code so that it assumes an uncompressed payload if it fails to find a properly compressed payload. Compare with the fatal error above: elfboot: Attempting to load payload. rom_stream: 0xfffc0000 - 0xfffdefff Uncompressing to RAM 0x01000000 Decoder scratchpad too small! olen = 0x00000000 done. Decompression failed. Assuming payload is uncompressed... Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 If you don't have CONFIG_COMPRESSED_PAYLOAD_LZMA and CONFIG_PRECOMPRESSED_PAYLOAD set and use an uncompressed payload, things are as before: elfboot: Attempting to load payload. rom_stream: 0xfffc0000 - 0xfffdefff Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 One can argue that this is a case of 'builder beware', but my counter argument is that anything that causes unexpected runtime breakage is really, really, really bad, and should be avoided where possible. This patch also fixes one erroneous comment. Signed-off-by: Ward Vandewege <ward@gnu.org> Acked-by: Myles Watson <mylesgw@gmail.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3542 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2008-08-27 23:53:11 +02:00
return 0;
}
state.Probs = (CProb *)scratchpad;
res = LzmaDecode(&state, src + LZMA_PROPERTIES_SIZE + 8, (SizeT)0xffffffff, &inProcessed,
dst, outSize, &outProcessed);
if (res != 0) {
printk(BIOS_WARNING, "lzma: Decoding error = %d\n", res);
If you have option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 option CONFIG_PRECOMPRESSED_PAYLOAD=1 set in Config.lb but accidentally use an uncompressed payload, coreboot (v2) bombs out like this: elfboot: Attempting to load payload. rom_stream: 0xfffc0000 - 0xfffdefff Uncompressing to RAM 0x01000000 Decoder scratchpad too small! Decoding error = 1 Unexpected Exception: 6 @ 10:04000408 - Halting Code: 0 eflags: 00010057 eax: 00000101 ebx: 04000400 ecx: 000003d4 edx: fffc0000 edi: 04000400 esi: 04000401 ebp: 04000400 esp: 0013dfb4 The attached patch modifies v2's lzma code so that it assumes an uncompressed payload if it fails to find a properly compressed payload. Compare with the fatal error above: elfboot: Attempting to load payload. rom_stream: 0xfffc0000 - 0xfffdefff Uncompressing to RAM 0x01000000 Decoder scratchpad too small! olen = 0x00000000 done. Decompression failed. Assuming payload is uncompressed... Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 If you don't have CONFIG_COMPRESSED_PAYLOAD_LZMA and CONFIG_PRECOMPRESSED_PAYLOAD set and use an uncompressed payload, things are as before: elfboot: Attempting to load payload. rom_stream: 0xfffc0000 - 0xfffdefff Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 One can argue that this is a case of 'builder beware', but my counter argument is that anything that causes unexpected runtime breakage is really, really, really bad, and should be avoided where possible. This patch also fixes one erroneous comment. Signed-off-by: Ward Vandewege <ward@gnu.org> Acked-by: Myles Watson <mylesgw@gmail.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3542 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2008-08-27 23:53:11 +02:00
return 0;
}
return outSize;
}