This series brings our zlib code more up to date. However, it drops an
important performance improvement that is required on some of our
supported platforms in order to boot Linux before the watchdog resets
the system. Furthermore, the "post increment" version of this
performance loop was not tested, so while we can fix it, it would then
require re-testing all platforms. At this point in time, we will revert
updating zlib (which has had a potential security issue since 2016) and
fix this in the v2024.10 release.
This reverts commit 4914263c9a, reversing
changes made to ef8ef5f77c.
Reported-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Tom Rini <trini@konsulko.com>
Get rid of zlib version which is not correct because of U-Boot related
changes and various CVE backports.
The change in inspired by Linux kernel commit 4f3865fb57a0 ("[PATCH]
zlib_inflate: Upgrade library code to a recent version") which described
ZLIB_VERSION removal as
"This patch also removes ZLIB_VERSION as it no longer has a correct value.
We don't need version checks anyway as the kernel's module handling will
take care of that for us. This removal is also more in keeping with the
zlib author's wishes (http://www.zlib.net/zlib_faq.html#faq24) and I've
added something to the zlib.h header to note its a modified version."
Author describes wish to follow this guidance at
https://www.zlib.net/zlib_faq.html#faq24:
"The license says that altered source versions must be "plainly marked". So
what exactly do I need to do to meet that requirement?
You need to change the ZLIB_VERSION and ZLIB_VERNUM #defines in zlib.h. In
particular, the final version number needs to be changed to f, and an
identification string should be appended to ZLIB_VERSION. Version numbers
x.x.x.f are reserved for modifications to zlib by others than the zlib
maintainers. For example, if the version of the base zlib you are altering
is 1.2.3.4, then in zlib.h you should change ZLIB_VERNUM to 0x123f, and
ZLIB_VERSION to something like 1.2.3.f-zachary-mods-v3. You can also update
the version strings in deflate.c and inftrees.c."
But U-Boot is not exact version that's why following the same style which
has been used by Linux kernel where ZLIB_VERSION is completely removed.
Signed-off-by: Michal Simek <michal.simek@amd.com>
While our copy of zlib is missing upstream commit 263b1a05b04e ("Allow
deflatePrime() to insert bits in the middle of a stream.") we do have
Z_FIXED support, and so the majority of the code changes in 5c44459c3b28
("Fix a bug that can crash deflate on some input when using Z_FIXED.")
apply here directly and cleanly. As this has been assigned a CVE, lets
go and apply these changes.
Link: 5c44459c3b
Reported-by: "Gan, Yau Wai" <yau.wai.gan@intel.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Drop inclusion of crc.h in common.h and use the correct header directly
instead.
With this we can drop the conflicting definition in fw_env.h and rely on
the crc.h header, which is already included.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
We often need the requirement that compressing those memory range start
from 0, but the default deflate code in zlib prevent us to do this.
Considering the special case of uboot, that it could access all memory
range, it is reasonable to be able to also take the address space from 0
into compression.
Signed-off-by: Lei Wen <leiwen@marvell.com>
