If the modules directory that corresponds to the version of the kernel
being built has been deleted, don't try to run depmod, which will
obviously fail.
This can happen for instance when the modules are stripped from the main
root filesystem, and placed into a separate filesystem image, so that
the root filesystem and the kernel can be updated separately.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 532fe9fb57)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On Ubuntu 18.04, make-4.1 emits spurious, incorrect "entering/leaving"
messages, which end up in the LINUX_VERSION_PROBED variable:
printf 'probed linux version: "%s"\n' "$(LINUX_VERSION_PROBED)"
probed linux version: "make[1]: Entering directory '/home/buildroot'
4.19.78-linux4sam-6.2
make[1]: Leaving directory '/home/buildroot/output/build/linux-linux4sam_6.2'"
First, the messages are displayed even though we do explicitly pass
--no-print-directory -s.
Second, the entering and leaving messages are not about the same
directory!
This *only* occurs in the following conditions:
- the user has the correct 0022 umask,
- top-level parallel is used (with or without PPD),
- initial -C is specified as well.
$ umask 0022
$ make -j16 -C $(pwd)
[...]
depmod: ERROR: Bad version passed make[1]:
[...]
(yes, 'make[1]:' is the string depmod is trying, and fails, to parse as
a version string).
If any of the three conditions above is removed, the problem no longer
occurs. Here's a table of the MAKEFLAGS:
| 0002 | 0022 |
----+-------+------------------------------------------------+--------------------------+
| no-j | --no-print-directory -- | |
noC | +------------------------------------------------+--------------------------+
| -j16 | -j --jobserver-fds=3,4 --no-print-directory -- | -j --jobserver-fds=3,4 |
----+-------+------------------------------------------------+--------------------------+
| no-j | --no-print-directory -- | w |
-C | +------------------------------------------------+--------------------------+
| -j16 | -j --jobserver-fds=3,4 --no-print-directory -- | w -j --jobserver-fds=3,4 |
----+-------+------------------------------------------------+--------------------------+
0002: umask == 0002
0022: umask == 0022
no-j: no -j flag
-j16: -j16 flag
noC: no -C flag
-C : -C /path/of/buildroot/
Only the bottom-right-most case fails...
This behaviour goes against what is documented:
https://www.gnu.org/software/make/manual/make.html#g_t_002dw-Option
5.7.4 The ‘--print-directory’ Option
[...]
you do not need to specify this option because ‘make’ does it for
you: ‘-w’ is turned on automatically when you use the ‘-C’ option,
and in sub-makes. make will not automatically turn on ‘-w’ if you
also use ‘-s’, which says to be silent, or if you use
‘--no-print-directory’ to explicitly disable it.
So this exactly describes our situation; yet 'w' is added to MAKEFLAGS.
Getting rid of the 'w' flag makes the build succeed again, so that's
what we do here (bleark, icky)...
Furthermore, the documented way to override MAKEFLAGS is to do so as a
make parameter:
https://www.gnu.org/software/make/manual/make.html#Options_002fRecursion
5.7.3 Communicating Options to a Sub-make
[...]
If you do not want to pass the other flags down, you must change the
value of MAKEFLAGS, like this:
subsystem:
cd subdir && $(MAKE) MAKEFLAGS=
However, doing so does not fix the issue. So we resort to pass the
modified MAKEFLAGS via the environment (bleark, icky)...
Fixes: #13141
Reported-by: Laurent <laurent@neko-labs.eu>
Reported-by: Asaf Kahlon <asafka7@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 3f6a40e9fa)
Signed-off-by: Peter Korsgaard <peter@korsgaard.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>
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>
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>
