CVE-2021-3575: A heap-based buffer overflow was found in openjpeg in
color.c:379:42 in sycc420_to_rgb when decompressing a crafted .j2k file. An
attacker could use this to execute arbitrary code with the permissions of
the application compiled against openjpeg.
Note that, although not explicitly specified in the changelog, version
3.7 renamed the file COPYING to LICENSE, requiring corresponding changes
in Bildroot related to the license file (specifically, the name and hash).
Release notes:
- bmap-tools 3.7:
* Use GitHub Actions for CI (#109)
* Add `poetry` for dependency management and `black` for code
formatting (#104)
* Add functionality for copying from standard input (#99)
* Switch from gpg to gpgme module (#103)
- bmaptool 3.8.0:
* use 'df -P' for POSIX portable output
* bmaptool has new maintainers
* bmaptool has a new home
* bmaptool is now only called 'bmaptool' and not one of a dozen such
variations
* switch to use an X.Y.Z versioning number scheme
package/bmap-tools: rename Kconfig prompt to bmaptool
Historically, the package was named bmap-tools, and that's the name
under which it was introduced in Buildroot. Since then, it has moved to
a new home (i. e. to https://github.com/yoctoproject/bmaptool) under the
Yocto Project umbrella, and got renamed to bmaptool. To avoid useless
churn, we keep the old symbols, and just refer to bmaptool in the
prompt.
As reported in the README file of the old GitHub URL (i.e.
https://github.com/intel/bmap-tools), "The code at this location is no
longer maintained and will likely be removed in the future. This project
has moved to https://github.com/yoctoproject/bmaptool".
Ben Hutchings [Thu, 11 Apr 2024 15:20:16 +0000 (17:20 +0200)]
package/skeleton-init-sysv: Set sticky bit on /dev/shm
/dev/shm is a world-writable directory, like /tmp, and should also
have the sticky bit set. Without this, any user can delete and
replace another user's files in /dev/shm.
This bug has been present since /dev/shm was added to the skeleton
/etc/fstab, but appears to have been fixed for systems using systemd
by commit 76fc9275f14e "system: separate sysv and systemd parts of the
skeleton" which went into Buildroot 2017.08.
Signed-off-by: Ben Hutchings <[email protected]> Fixes: 22fde22e35f98f7830c2f8955465532328348cd1 Signed-off-by: Yann E. MORIN <[email protected]>
TestATFVexpress is using vexpress_aemv8a_juno as as u-boot defconfig
but the Buildroot defconfig of this board was removed in 2022.11 [1]
Since both TestATFVexpress and TestATFAllwinner are now using mainline
ATF, we don't really need several ATF test anymore. Initially [2],
several runtime test were added to test ATF/U-Boot combinations when
ATF was provided by a vendor: vexpress (mainline), Allwinner and
Marvell.
support/testing: sync TestATFAllwinner with orangepi_zero_plus2_defconfig
u-boot-2021.04 seems to be broken when pylibfdt support is enabled
and the latest python3/setuptools are used.
Since the TestATFAllwinner is using bananapi_m64 as u-boot defconfig
but the Buildroot defconfig of this board was removed in 2022.11 [1]
update TestATFAllwinner to use a newer BSP. Use the one provided
by orangepi_zero_plus2_defconfig.
support/testing: regenerate .checkpackageignore used in TestCheckPackage
Commit ccb4e5db5c ("utils/check-package: emit library name along with check function name")
updated the .checkpackageignore format but forgot to update
.checkpackageignore files used in TestCheckPackage.
Keep .checkpackageignore_outdated as is since it must be outdated.
The last version bump removed python-pyopenssl runtime dependency but
doing so also removed the python-cryptography runtime depdency [1] that
is actually a direct runtime dependency.
While at it, update BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS
dependency comment.
The last version bump removed python-setuptools runtime dependency
but doing so also removed the python3-pyexpat and python3-zlib
runtime depdencies [1] that are actually direct runtime
dependencies.
The license file was updated for two reasons:
* This version now bundles ntlmclient. NTLM support is disabled by
the buildroot package.
* The bundled zlib version (that buildroot does not use) was updated and
its copyright years changed.
This version also adds support for using the SSH binary (at an hardcoded
/usr/bin/ssh path) instead of using libssh2.
/home/buildroot/instance-0/output-1/build/php-8.3.4/Zend/zend_call_stack.c:39:11: fatal error: pthread.h: No such file or directory
39 | # include <pthread.h>
| ^~~~~~~~~~~
Peter Korsgaard [Sun, 24 Mar 2024 18:01:28 +0000 (19:01 +0100)]
configs/nezha_defconfig: use mainline Linux 6.6.22
The D1 support is now in mainline, so use that instead. There is no
dedicated nezha defconfig, so use the riscv defconfig. This defconfig has
most drivers as modules, so add mdev to ensure they get correctly loaded.
The defconfig does not have USB gadget/OTG support, so enable that using a
config fragment to make the USB-C connector work and get rid of the
following warning:
[ 7.233418] musb-sunxi 4100000.usb: Invalid or missing 'dr_mode' property
[ 7.240330] musb-sunxi: probe of 4100000.usb failed with error -22
Vincent Fazio [Wed, 3 Apr 2024 21:18:05 +0000 (16:18 -0500)]
package/python3: fix cross builds when host and target use the same SOABI
When python performs a cross compile, it uses a host interpreter to run
steps on behalf of the foreign architecture to finalize the build.
When performing these steps, foreign modules may be loaded if the SOABI
matches that of the host. This can lead to issues if the modules are
linked against a libc not available on the host or if the binaries
include instructions unsupported by the host.
For now, patch the foreign libraries out of PYTHONPATH and explicitly
define the path to sysconfigdata so builds can complete without error.
This method currently passes all upstream CI pipelines [0] and should
also work (with some modifications) for the migration to 3.12 [1].
Note: this commit only deals with glibc and its internal libcrypt (or
lack thereof); other C libraries, musl and uClibc-NG, are not considered.
libcrypt from glibc has been deprecated for a long time, and it has now
been entirely dropped with glibc 2.39. Now, packages that need crypt(3)
features need to explicitly depend on the libxcrypt pacakge.
However, the set of files installed both by glibc and libxcrypt is not
empty:
The two libraries have different SO_NAME, so they do not conflict on the
library filename. However, the .so synlink is present in both, and thus
conflicts. The header and the static library also conflict.
So, the situation is that, with a glibc 2.39 or later, packages have to
use libxcrypt, which is a drop-in replacement. With glibc 2.38 or
earlier, they can use either.
Since we already bumped to glibc 2.39 for the internal toolchain, we
have already converted quite a few packages to use libxcrypt. That works
well with an internl toolchain, because glibc does not install the
conflicting files.
However, for external toolchains, we may very well end up in three
situations:
- a glibc 2.39 or later, without libcrypt
- a glibc 2.39 or later, without libcrypt, but with libxcrypt [0]
- a glibc 2.38 or earlier with libcrypt
In the first case, all is OK and we are in a situation similar to the
internal toolchain, but in the latter two cases, we end up with a
conflict.
We could introduce BR2_TOOLCHAIN_EXTERNAL_HAS_LIBCRYPT os something
along those lines, but this is going to be a bit complex on packages,
which would have to select LIBXCRYPT if GLIBC && !_HAS_LIBCRYPT.
So, to simplify things, we want to get the external toolchains into a
situation similar to the internal one, where libcrypt is not provided by
the toolchain; packages have to select libxcrypt for glibc toolchains,
without having to care whether this is an internal or external toolchain
or some more complex conditions.
So, we remove from staging whatever could be used to compile and link
with libcrypt. We however keep the SO_NAME file, if it exists, and we
also install it in target/, for those pre-built binaries that may be
linked with it [1]. The glibc SO_NAME has always been libcrypt.so.1, so
this is what we copy exactly, to avoid copying the libxcrypt one, which
is libcrypt.so.2.
[0] that could happen if a toolchain provider tried to be helpful and
suplies a toolchain with libxcrypt to be trasnparent to users, in which
case that would conflict with ours...
[1] if such a prebuilt binary (executable or library) is used with a
glibc 2.39 or later toolchain, it will obviously not work at all.
libxcrypt is supposed to be a drop-in replacement for glibc's libcrypt,
so we could look into symlinking libcrypt.so.1 to libcrypt.so.2. In a
later patch, maybe...
Romain Naour [Sun, 3 Mar 2024 23:03:55 +0000 (00:03 +0100)]
package/ti-k3: switch ti_am6{2,4}x_sk_defconfig to HS-FS by default
From Andreas Dannenberg (TI K3 architect) [1]:
"HS-FS should be the default for all TI AM6x devices. This is our
"production silicon" and what's used for (almost) all projects,
especially new projects. This being said having support for GP device
variants still is desirable for existing boards/projects, such as the
current BeaglePlay boards (amongst earlier version of TI starter kit
EVMs for AM6x)."
See further details on e2e Forum [2]:
"Unfortunately with this transition any existing GP device based AM62x
(and AM64x) boards will no longer boot with MMC/SD card images generated"
For such existing GP device based AM62x (and AM64x) boards, users have
to provide the tiboot3.bin name using BR2_TARGET_TI_K3_R5_LOADER_TIBOOT3_BIN.
Since all AM62 and AM64 defconfig has been updated to use binman
and ti-k3-image-gen has been removed, binman is now mandatory
for all TI K3 SoC. So remove BR2_TARGET_TI_K3_R5_LOADER_USE_BINMAN
option since since it can't be disabled anymore.
We can remove BR2_TARGET_TI_K3_R5_LOADER_USE_BINMAN without
legacy handling since this option is not part of any Buildroot
release.
While at it, add one more like to binman dependencies in comments.
Previoulsy (without binman), when a TI K3 SoC using Combined binary
with a split firmware boot method was used (am62ax or am62x) [1], the
user had to select BR2_TARGET_UBOOT_NEEDS_TI_K3_DM in the defconfig
to provide Device Manager firmware provided by ti-k3-boot-firmware.
With binman, this option is no longer necessary since
ti-k3-boot-firmware package is already in the u-boot dependency and the
path to DM and SYSFW binaries are provided by BINMAN_INDIRS.
We are going to remove ti-k3-image-gen, so binman is now mandatory on
all TI K3 SoCs.
Dario Binacchi [Fri, 1 Mar 2024 13:36:18 +0000 (14:36 +0100)]
configs/ti_am64x_sk_defconfig: bump U-Boot version to 2024.01
The 2024.01 version of U-Boot for the am64x-sk board has introduced two
major changes:
- The device tree k3-am642-sk.dtb is no longer searched in /boot, but in
/boot/dtb/ti. Hence, the disabling of BR2_LINUX_KERNEL_INSTALL_TARGET
and the use of extlinux.conf for the proper loading of the device tree.
Furthermore, the parameter BR2_ROOTFS_POST_SCRIPT_ARGS was used to
auto-generate the extlinux.conf file so that developers can change the
kernel loading options by modifying the .config.
- U-Boot is capable of building tiboot3.bin using Binman. So it's no longer
necessary to use custom tools like ti-k3-image-gen.
- Use a custom tiboot3.bin since the default is "hs-fs",
but the ti_am64x_sk_defconfig expect the "gp" one.
Dario Binacchi [Fri, 1 Mar 2024 13:36:15 +0000 (14:36 +0100)]
board/ti/am62x-sk: generalize post-build.sh
Removing any explicit reference to the ti_am62x_sk_defconfig
configuration, the script can also be used by other configurations or at
least by ti_am64x_sk_defconfig.
Dario Binacchi [Fri, 1 Mar 2024 13:36:13 +0000 (14:36 +0100)]
configs/ti_am62x_sk_defconfig: bump U-Boot version to 2024.01
The 2024.01 version of U-Boot for the am62x-sk board has introduced two
major changes:
- The device tree k3-am625-sk.dtb is no longer searched in /boot, but in
/boot/dtb/ti. Hence, the disabling of BR2_LINUX_KERNEL_INSTALL_TARGET
and the use of extlinux.conf for the proper loading of the device tree.
Furthermore, the parameter BR2_ROOTFS_POST_SCRIPT_ARGS was used to
auto-generate the extlinux.conf file so that developers can change the
kernel loading options by modifying the .config.
- U-Boot is capable of building tiboot3.bin using Binman. So it's no longer
necessary to use custom tools like ti-k3-image-gen.
- Use a custom tiboot3.bin since the default is "hs-fs",
but the ti_am62x_sk_defconfig expect the "gp" one
boot/ti-k3-r5-loader: install tiboot3.bin and sysfw.itb to BINARIES_DIR
With binman support enabled, u-boot for k3 r5 core (ti-k3-r5-loader)
install different target image (tiboot3*.bin) depending on the K3
SoC boot ROM:
- General Purpose devices (gp)
- High Security - Field Securable devices (hs-fs)
- High Security - Security Enforcing devices (hs)
An additional firmware binary is required on certain TI K3 devices such
as AM65 and J721e due to the "Split binary" boot flow [1]:
- Split binary with a combined firmware: (eg: AM65)
- Combined binary with a combined firmware: (eg: AM64)
- Split binary with a split firmware: (eg: J721E)
- Combined binary with a split firmware: (eg: AM62)
K3 SoC using Split Binary Boot Flow also requires sysfw-*.itb file
to boot (eg: am65, j721e). Only tiboot3*.bin is needed for other
boot flow.
From [1]:
"It's important to rename the generated tiboot3.bin and sysfw.itb
to match exactly tiboot3.bin and sysfw.itb as ROM and the wakeup
UBoot SPL will only look for and load the files with these names."
See the (not exhaustive) list of all tiboot3*.bin and sysfw*.itb file
variant found in meta-ti:
A tiboot3.bin symlink is provided as default choice:
tiboot3.bin -> tiboot3-am62x-hs-fs-evm.bin
On this board, the tiboot3.bin symlink links to the hs-fs variant
but it not always de case for all TI K3 devices.
(ex: J721e use gp variant by default).
The tiboot3.bin symlink links the -gp, -hs-fs, -hs tiboot3 binary
according to where "symlink = "tiboot3.bin";" line is located in
k3-*binman.dtsi.
As reported by Michael Walle [2], such firmware name can also be
customized by a SBC vendor [3], so we can't always be sure which
firmware to use.
If required, let the user provide a custom tiboot3 or sysfw firmware
name from the defconfig. Otherwise use the default firmware choice
by copying tiboot3.bin and sysfw.itb symlinks.
Since crucible commit 7fe0bb96da65 ("move to BSD style license") the
license has been changed to BSD-3. This changed happened for the
2023.11.02 release of crucible, to which the Buildroot package was
bumped in Buildroot commit be3f95ed14559f8a9739a12cff604add622b0416.
npth.c:392:21: error: unknown type name 'npth_rwlock_t'; did you mean 'npth_cond_t'?
392 | npth_rwlock_rdlock (npth_rwlock_t *rwlock)
| ^~~~~~~~~~~~~
| npth_cond_t
Recent version of U-Boot use binman to provide a mechanism for building
images, from simple SPL + U-Boot combinations, to more complex
arrangements with many parts.
This tool uses additional host python modules that must be provided by
Buildroot. So introduce a new option BR2_TARGET_UBOOT_USE_BINMAN to
add additional host packages in U-Boot build dependency to use binman.
The binman requirement is directly included in buildman dependency
(tools/buildman/requirements.txt) since within U-Boot, binman is
invoked by the build system, here buildman [1].
Recent version of U-Boot use binman to provide a mechanism for building
images, from simple SPL + U-Boot combinations, to more complex
arrangements with many parts.
This tool uses additional host python modules that must be provided by
Buildroot. So introduce a new option
BR2_TARGET_TI_K3_R5_LOADER_USE_BINMAN to add additional host packages
in U-Boot build dependency to use binman.
When BR2_TARGET_TI_K3_R5_LOADER_USE_BINMAN is set, BINMAN_INDIRS
environment variable to provide the directory to search for binary
blobs and select the packages required by binman. Make sure that
ti-k3-boot-firmware package has been installed before building
ti-k3-r5-loader in order to provide such firmwares.
The BR2_TARGET_TI_K3_R5_LOADER_USE_BINMAN option is currently needed
since we are in the middle of the process to switch TI AM62 and AM64
board defconfig to binman. Keep BR2_TARGET_TI_K3_R5_LOADER_USE_BINMAN
disabled for them until the u-boot/ti-k3-r5-loader version bump to
2024.01.
The dependency of binman is not really easy to follow. First we have
the packages list from binman.rst [1] then we have to install
additional python modules [2]. Maybe in the future it will be
necessary to add host-lzma and host-lz4 in the dependencies list.
projects / buildroot-mgba.git / log