Drop all duplicate newlines. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Now that the release has happened, bring back the update to zlib. This reverts commit bbacdd3ef7762fbdeab43ceea5205d1fd0f25bbd. Signed-off-by: Tom Rini <trini@konsulko.com>
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 4914263c9a14315390d3ccc4816cf3a94cfd156d, reversing changes made to ef8ef5f77c9a998f76a48277a883af1645b54117. 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: https://github.com/madler/zlib/commit/5c44459c3b28a9bd3283aaceab7c615f8020c531
Reported-by: "Gan, Yau Wai" <yau.wai.gan@intel.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
In contrast to the C99 standard [1] our putc() takes only one argument. [1] ISO/IEC 9899:1999 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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>
Signed-off-by: Lei Wen <leiwen@marvell.com>