Commit a4eef9a395 (linux: introduce BR2_KERNEL_DTB_KEEP_DIRNAME)
introduced a new config option, but its name was not matching the
naming-scheme of the other config options.
Rename it.
We don't need legacy handling, because that config option was added very
recently and was never part of a release.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In linux, newer architectures like ARM64 and RISC-V keep their device
tree sources organized by subdirectories. When these device trees are
installed by the kernel they will keep the directory names. But
buildroot strips the prefixes when installing them into /boot or the
images directory.
Sometimes the bootloader references the device tree by name (e.g.
u-boot has the environment variable 'fdtfile') which also includes
the prefix directory.
Make it possible to keep this prefix during installation, so we can
be compatible with other distributions and make it easier for the
user, because he doesn't have to change that environment variable.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
A few conflicts had to be resolved:
- Version number and hash for mesa3d-headers/mesa3d
- Patches added in qemu, and the qemu version number
- The gnuconfig README.buildroot
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
perf by itself is not a standalone package; instead, it is part of a
bigger package, linux-tools.
Even though perf is the only one to need kernel .config fixups, we still
do it in a generic way, as it blends nicely in the existing variables,
which all use a loop over all the tools.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The soon-to-be-released linux 5.7 has changed the way it detects the
ability of gcc to use plugins, when it dropped support for gcc 4.7 or
older [0].
To detect the ability to use gcc plugins, the kernel has to check
whether the host gcc is capable enough to build them.
When we call one of the configurator for the Linux kernel, we explicitly
pass a value of HOSTCC=$(HOSTCC_NOCCACHE), because there might be a
discrepancy between the ncurses headers and libraries as found by the
Linux kconfig build [1] [2].
But then, when we build the kernel, we pass another value to use [3]
HOSTCC="$(HOSTCC) $(HOST_CFLAGS) $(HOST_LDFLAGS)" which boils down to
roughly: gcc -I.../host/include -L.../host/lib -Wl,-rpath,.../host/lib
This is needed so that at build time, the kernel can build host tools
that link with our openssl et al.
So, the two HOSTCC we pass to the kernel may have different behaviours.
For example, on a machine where gmp is missing in the system, it is
available in $(O)/host/ when using an internal toolchain (and under a
few other conditions).
In that case, when configuring the kernel, it decides that the host
compiler can't build plugins, so the dependencies of CONFIG_GCC_PLUGINS
are not met, and that option is not present in the linux' .config file
(neither as "=y" nor as "is not set"). But then, when we build the
kernel, the host compiler suddenly becomes capable of building the
plugins, and the internal syncconfig run by the kernel will notice that
the dependencies of CONFIG_GCC_PLUGINS are now met, and that the user
shall decide on its value. And this blocks a build on an interactive
console (abbreviated):
* Restart config...
* GCC plugins
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) _
But most problematic is the behaviour when run in a shell that is not
interactiove (e.g. a CI job or such) (abbreviated):
* Restart config...
* GCC plugins
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW)
Error in reading or end of file.
Generate some entropy during boot and runtime (GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW)
Error in reading or end of file.
Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT) [N/y/?] (NEW)
Error in reading or end of file.
* Memory initialization
Initialize kernel stack variables at function entry
> 1. no automatic initialization (weakest) (INIT_STACK_NONE)
2. zero-init structs marked for userspace (weak) (GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
3. zero-init structs passed by reference (strong) (GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
4. zero-init anything passed by reference (very strong) (GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW)
choice[1-4?]:
Error in reading or end of file.
Poison kernel stack before returning from syscalls (GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW)
Error in reading or end of file.
Enable heap memory zeroing on allocation by default (INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON) [N/y/?] n
The most obvious and simple solution would be to unconditionally disable
gcc plugins altogether, in the KCONFIG_FIXUP hook. But that can't work
either, because after applying the fixups, we call olddefconfig (or the
likes) with the incapable HOSTCC, so the disabled option would be removed
anyway, and we'd be back to square one.
So, in addition to the above, we also forcibly hack the same call just
before actually building the kernel.
Note that the two are needed: the one in the fixups is needed for those
that have a system that already allows building gcc plugins, and the
second is needed in the other case, where the system does not allow it
but would work with our additional headers and libs in $(O)/host/. The
two ensure there is a very similar experience in the two situations.
Forcibly disabling the use of gcc plugins is not a regression on our
side: it has never been possible to do so so far. We're now making sure
that can't work by accident.
Reported-by: Ganesh <ganesh45in@gmail.com>,
Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Michael Walle <michael.walle@kontron.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In version 5.6 a minor change was made to this file, stating tht "[a]ll
contributions to the Linux Kernel are subject to this COPYING file",
and hence the hash changed.
We can update the hash, because the licensing information is only
accounted for the "latest" version, so the hash change will not impact
older kernel versions as the user would have to switch to a non-latest
kernel.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Bumping the hashes for CIP and CIP RT.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch bumps Linux CIP RT version to 4.19.115-cip24-rt9.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch bumps Linux CIP version to v4.19.118-cip25.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Adam Duskett <aduskett@gmail.com>
Cc: Clayton Shotwell <clayton.shotwell@rockwellcollins.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Marcus Folkesson <marcus.folkesson@gmail.com>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Reviewed-by: Adam Duskett <aduskett@gmail.com>
Tested-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Adam Duskett <aduskett@gmail.com>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Carlos Santos <unixmania@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Anders Darander <anders@chargestorm.se>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Carlos Santos <unixmania@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, the linux kernel will apply some fixups on its .config file,
based on whether some packages are enabled or not. That list of
conditional fixups is getting bigger and bigger with each new package
that needs such fixups, culminating with the pending firewalld one [0].
Furthermore, these fixups are not accessible to packages in br2-external
trees.
Add a new per-package variable, that packages may set to the commands to
run to fixup the kernel .config file, which is added at the end of the
linux' own fixups.
This opens the possibility to write things like;
define FOO_LINUX_CONFIG_FIXUPS
$(call KCONFIG_ENABLE_OPT,BLA)
endef
Of course, it also opens the way to run arbitrary commands in there, but
any alternative that would be declarative only, such as a list of
options to enable or disable (as an example):
FOO_LINUX_CONFIG_FIXUPS = +BAR -FOO +BUZ="value"
.. is not very nice either, and such lists fall flat when a value would
have a space.
For packages that we have in-tree, we can ensure they won't play foul
with their _LINUX_CONFIG_FIXUPS. For packages in br2-external trees,
there's nothing we can do; users already have the opportunity to hack
into the linux configure process by providing LINUX_PRE_CONFIGURE_HOOKS
or LINUX_POST_CONFIGURE_HOOKS anyway...
.. which brings the question of why we don't use that to implement the
per-package fixups. We don't, because _PRE or _POST_CONFIGURE_HOOKS are
run after we run 'make oldconfig' to sanitise the mangled .config.
[0] http://lists.busybox.net/pipermail/buildroot/2020-March/278683.html
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Notice: 5.5.x is now EOL, so should be dropped at the next version bump.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Using AppArmor requires support in the kernel, so do for AppArmor what
we did for SElinux, and enabled the necessary options.
Note that a single LSM can be the default one, so as of today, SELinux
wins, by virtue of being the last to be enabled.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
[yann.morin.1998@free.fr:
- don't force DEFAULT_SECURITY_APPARMOR, it does not exist in all
kernel versions
- move closer to SELinux
- split into its own patch, write a commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Tested-by: Angelo Compagnucci <angelo@amarulasolutions.com>
The help text of BR2_LINUX_KERNEL_IMAGE_NAME is somewhat incomplete,
in the sense that it assumes just a filename can be passed, while it
can be a relative path, such as 'compressed/vmlinux.bin.z'. So make it
clear that such paths are relative to arch/ARCH/boot/.
Also, drop the part about this being only useful for Xtensa as this is
not true: on MIPS it might be needed as well for some specific image
types.
Reported-by: Paul Cercueil <paul@crapouillou.net>
Cc: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Linux kernel image is typically found in arch/ARCH/boot/, which is
why LINUX_IMAGE_PATH is defined as:
LINUX_IMAGE_PATH = $(LINUX_ARCH_PATH)/boot/$(LINUX_IMAGE_NAME)
However, on MIPS, some kernel image types are available from
arch/mips/boot/compressed, or even at the top-level directory. For
such cases, LINUX_IMAGE_NAME might be set (using
BR2_LINUX_KERNEL_IMAGE_NAME) to values such as:
compressed/vmlinux.bin.z
or
../../../uzImage.bin
Except that the line:
$(INSTALL) -m 0644 -D $(LINUX_IMAGE_PATH) $(1)/$(LINUX_IMAGE_NAME)
will lead to such images be installed in:
$(TARGET_DIR)/boot/compressed/vmlinux.bin.z
$(BINARIES_DIR)/compressed/vmlinux.bin.z
and:
$(TARGET_DIR)/boot/../../../uzImage.bin
$(BINARIES_DIR)/../../../uzImage.bin
which of course is completely bogus.
So let's install them under their name, not their full relative path
to arch/ARCH/boot/.
Reported-by: Paul Cercueil <paul@crapouillou.net>
Cc: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
[yann.morin.1998@free.fr:
- bump to 5.5.13
- rebase on top of master
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
When a package installs a kernel module, it is currently not possible to
have it loaded with modprobe or when the kernel requests an alias for
it, as the module is not listed in /lib/modules/<kernel-version>/modules.dep
and the associated files.
So, we need to run depmod after all packages are installed, to register
any such out-of-tree module.
This means we should be able to let go of calling depmod at the time the
kernel is installed, but if we pass an invalid command, the kernel
whines:
DEPMOD 5.4.27
./scripts/depmod.sh: 46: /dev/null: Permission denied
make[2]: *** [Makefile:1326: _modinst_post] Error 126
This is because the kernel does not directly call to depmod, but uses a
wrapper that is not happy if depmod is not depmod.
Since the call to depmod does not cost much, we just keep it.
Signed-off-by: Carlos Santos <unixmania@gmail.com>
[yann.morin.1998@free.fr:
- keep calling depmod when installing kernel
- expand commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Enabling SELinux support in the kernel requires several options, many
of which are in different areas. These options are as follows:
- CONFIG_AUDIT
- CONFIG_DEFAULT_SECURITY_SELINUX
- CONFIG_INET
- CONFIG_NET
- CONFIG_SECURITY
- CONFIG_SECURITY_NETWORK
- CONFIG_SECURITY_SELINUX
As such, if a user selects the libselinux package, it is much easier
to select these options for them, much like we already do with other
packages such as systemd or iptables.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit de591c5c3a (package/wireguard-linux-compat: new package) split up
the wireguard package in wireguard-tools and wireguard-linux-compat, but
forgot to update the conditional in linux.mk, so the kernel config fixups
needed for wireguard are no longer applied.
Update the conditional to use the BR2_PACKAGE_WIREGUARD_LINUX_COMPAT symbol
instead.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The content of COPYING changed between v4.16 and v4.17. Since kernels
before and after the change are supported, storing the hash for this
file will cause an error during "make legal-info" when a kernel with the
respective other hash is being used.
So, for the kernel, we do like we did for ATF: the license file is only
listed for the latest version.
In the process, add the missing license files referenced from COPYING
and align the fields to the new spacing convention.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
[yann.morin.1998@free.fr:
- only list the licenses files for the latest version
- restore the hash for COPYING
- introduce hashes for the two new license files
- expand commit log accordingly
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch bumps Linux CIP RT version to 4.19.98-cip19-rt7.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
