This commit wires-up the toolchain-external-bootlin package into
Buildroot by:
- Adding
toolchain/toolchain-external/toolchain-external-bootlin/Config.in,
which is not generated by the bl-toolchains-gen script as it is a
static file that does not depend on the list and characteristics of
available Bootlin toolchains.
- Including that file, as well as the Config.in.options file, from
toolchain/toolchain-external/Config.in.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Titouan Christophe <titouan.christophe@railnova.eu>
Tested-by: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This commit adds the contents of the
toolchain/toolchain-external/toolchain-external-bootlin/ files
generated by bl-toolchains-gen, unmodified.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
https://toolchains.bootlin.com/ has been providing for a few years a
number of ready-to-use pre-built toolchains, for a wide range of
architectures (which it turns out, are all built using Buildroot).
While toolchains.bootlin.com provides Buildroot config fragments to
easily use those toolchains with Buildroot (see [0] for example), this
is not visible anywhere. So instead, we would like to add support for
these toolchains in Buildroot just like we have existing support for
Linaro, ARM, Synopsys, etc. toolchains.
[0] https://toolchains.bootlin.com/downloads/releases/toolchains/aarch64/fragments/aarch64--glibc--bleeding-edge-2020.02-2.frag
However, the number of toolchains provided by toolchains.bootlin.com
is really large, and they are regularly updated. Maintaining that
manually would be time consuming and error-prone. So instead, this
commit introduces a script that automatically generates:
- toolchain/toolchain-external/toolchain-external-bootlin/Config.in.options
- toolchain/toolchain-external/toolchain-external-bootlin/toolchain-external-bootlin.mk
- toolchain/toolchain-external/toolchain-external-bootlin/toolchain-external-bootlin.hash
- support/testing/tests/toolchain/test_external_bootlin.py
We create a single external toolchain package, with a Kconfig "choice"
as a sub-option to select the toolchain variant to be used. The script
contains a Python dict that provides the mapping between the
toolchains provided by toolchains.bootlin.com, and the architecture
options/variants they are applicable to.
The test cases allow to verify that the toolchain configuration is
correct, and that it is able to build a Busybox based system. It
doesn't do any runtime testing as such testing is already done by
toolchains.bootlin.com: the test cases here are only meant to verify
that the toolchain-external-bootlin package works as expected.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Titouan Christophe <titouan.christophe@railnova.eu>
Tested-by: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since the go.mod integration, the <pkg>_WORKSPACE variable is useless,
so drop it.
Reported-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that we have switched to the go.mod integration, all Go packages
are built with -mod=vendor, so there's no need to have custom GOFLAGS
in mender-artifact.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With the go.mod integration, the <pkg>_WORKSPACE variable has become
useless, drop it.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With the go.mod integration, the DOCKER_ENGINE_SRC_SUBDIR has become
useless, drop it.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With the go.mod integration, the <pkg>_WORKSPACE variable is no longer
needed, drop it.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With the go.mod integration, the <pkg>_WORKSPACE variable has become
useless, so drop it.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The Go compiler needs to know the "import path" to the root of package
source repositories. Previously, this was done by creating a fake
_gopath in the build directory and symlinking the package source into
that path.
Go has deprecated the GOPATH mechanism in favor of a new approach -
Modules - which specifies the root import path (and dependencies) in a
"go.mod" file. This commit moves Buildroot to use the new go.mod
approach, which requires:
- Passing GO111MODULE=on when building host or target Go packages.
- Passing GOPROXY=off and -mod=vendor to prevent the Go module system
from downloading by itself sources from the Internet. We currently
only support Go packages that have all their dependencies in their
source tree in "vendor" directories.
- Specifying a <pkg>_GOMOD variable, which is used both to create a
minimal go.mod file in the package source tree if it exists, and to
invoke the right build targets. Indeed, all elements in
<pkg>_BUILD_TARGETS are now relative to <pkg>_GOMOD.
Reference: https://github.com/golang/go/wiki/Modules
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In preparation for the go.mod integration, define the DOCKER_CLI_GOMOD
variable.
We also use it as a handy shortcut when defining DOCKER_CLI_LDFLAGS.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In preparation for the go.mod integration, define the
DOCKER_ENGINE_GOMOD variable.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In preparation for the go.mod integration, define the
DOCKER_CONTAINERD_GOMOD variable.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that GO_TARGET_ENV and GO_HOST_ENV are just aliases to
HOST_GO_TARGET_ENV and HOST_GO_HOST_ENV, drop the former two, and use
the latter two directly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
There is no point in having some common Go env variables defined in
pkg-golang.mk:GO_COMMON_ENV, and some in
package/go/go.mk:HOST_GO_COMMON_ENV. Let's move all of them to
package/go/go.mk:HOST_GO_COMMON_ENV.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
HOST_GO_HOST_ENV is explicitly specifying
HOST_CGO_{CFLAGS,CXXFLAGS,LDFLAGS}, so let's do the same for target
packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
A few variables are common between HOST_GO_TARGET_ENV and
HOST_GO_HOST_ENV, so let's introduce a HOST_GO_COMMON_ENV variable for
those few common ones (which will increase in follow-up commits).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
package/go/go.mk provides a HOST_GO_TARGET_ENV which provides a useful
set of environment variables needed to build target Go packages.
For host packages, we simply have package/pkg-golang.mk defining
GO_HOST_ENV to specify CFLAGS/LDFLAGS, but that's it: we don't pass an
explicit path to the compiler, we don't pass GO111MODULE, GOCACHE,
GOROOT, etc.
This commit introduces a HOST_GO_HOST_ENV variable that provides the
appropriate set of environment variables to use when building host
golang packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The upstream tarball provides an already generated configure script,
which works fine, so there's no need to AUTORECONF.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since commit 0e2be4db8a
("package/pkg-generic: make file list logic parallel build
compatible"), the commands executed at the every end of the build
to assemble the list of files installed by the different packages
are visible in the make output. They are quite noisy, and clutter
the output.
The other commands in target-finalize are also hidden using "@",
so we should also do the same for those commands. But that hurts
debuggability, so we use $(Q) (the existing '@'s can be changed
in a followup patch).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: use '$(Q)', not '@']
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
watchdog is a flexible watchdog daemon that improves on the already
available Busybox watchdog daemon by providing more advanced features,
like defining custom system status checks and executing repair scripts
to react upon invariants that don't hold.
Due to "watchdog" being also provided by Busybox, we need to make that
package/watchdog installs the watchdog binary in the same place as
Busybox (i.e in /sbin), and need to add a dependency of Busybox on
this new watchdog package.
Signed-off-by: Alejandro González <alejandro.gonzalez.correo@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
By default, go will attempt to download needed modules before building, which
is not desirable. This behavior also causes permission issues when cleaning,
as go downloads modules as read-only by default. Because mender-artifact
includes the modules in the vendor directory, mod=vendor prevents the package
from downloading the go modules during the build process and prevents
permission issues when cleaning.
Fixes:
http://autobuild.buildroot.net/results/d5bcaca73ae74fe8b0ebd39b6331564cd639fb66
Signed-off-by: Mirza Krak <mirza.krak@northern.tech>
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes the following security issues:
CVE-2020-15810: HTTP(S) Request Smuggling
Due to incorrect data validation Squid is vulnerable to HTTP Request
Smuggling attacks against HTTP and HTTPS traffic. This leads to cache
poisoning.
https://github.com/squid-cache/squid/security/advisories/GHSA-3365-q9qx-f98m
CVE-2020-15811: HTTP(S) Request Splitting
Due to incorrect data validation Squid is vulnerable to HTTP Request
Splitting attacks against HTTP and HTTPS traffic. This leads to cache
poisoning.
https://github.com/squid-cache/squid/security/advisories/GHSA-c7p8-xqhm-49wv
CVE-2020-24606: Denial of Service processing Cache Digest Response
Due to Improper Input Validation Squid is vulnerable to a Denial of Service
attack against the machine operating Squid.
https://github.com/squid-cache/squid/security/advisories/GHSA-vvj7-xjgq-g2jg
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
wolfSSL version 4.5.0 contains 6 vulnerability fixes: 2 fixes for TLS 1.3,
2 side channel attack mitigations, 1 fix for a potential private key leak
in a specific use case, 1 fix for DTLS including those 3 CVEs:
- Fix CVE-2020-12457: An issue was discovered in wolfSSL before 4.5.0.
It mishandles the change_cipher_spec (CCS) message processing logic
for TLS 1.3. If an attacker sends ChangeCipherSpec messages in a
crafted way involving more than one in a row, the server becomes stuck
in the ProcessReply() loop, i.e., a denial of service.
- Fix CVE-2020-15309: An issue was discovered in wolfSSL before 4.5.0,
when single precision is not employed. Local attackers can conduct a
cache-timing attack against public key operations. These attackers may
already have obtained sensitive information if the affected system has
been used for private key operations (e.g., signing with a private
key).
- Fix CVE-2020-24585: An issue was discovered in the DTLS handshake
implementation in wolfSSL before 4.5.0. Clear DTLS application_data
messages in epoch 0 do not produce an out-of-order error. Instead,
these messages are returned to the application.
Also update hash of LICENSING as well as WOLF_LICENSE due to later
verbage update with
970391319bhttps://www.wolfssl.com/docs/security-vulnerabilities/
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix CVE-2020-17498: In Wireshark 3.2.0 to 3.2.5, the Kafka protocol
dissector could crash. This was addressed in
epan/dissectors/packet-kafka.c by avoiding a double free during LZ4
decompression.
https://www.wireshark.org/security/wnpa-sec-2020-10.html
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Also separate the fields in the hash file by two spaces and add pgp
signature check.
Since we're now using the default value for POWERTOP_SOURCE, drop this
variable definition.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Mainline Linux now has basic s500/roseapplepi support, so switch to that to
get rid of the dependency on gcc7. Add two patches for the dts / fix that
didn't make it for kernel 5.7.
The mainline kernel does not yet have support for the mmc interface, so
change to initramfs for now. Patches for mmc support have been posted
recently, so this can be reverted once they show up in a stable kernel:
https://lore.kernel.org/lkml/cover.1593124368.git.cristian.ciocaltea@gmail.com/
The owl serial port is called ttyOWLn in mainline, so adjust the bootargs to
match. Also drop the unneeded execute permission on uEnv.txt.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes the following security issue:
CVE-2016-10228: An infinite loop has been fixed in the iconv program when
invoked with the -c option and when processing invalid multi-byte input
sequences. Reported by Jan Engelhardt.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
openal uses std::max_align_t since version 1.20.0 and
585b0cf3be
As a result, it is affected by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56019
and the build with gcc <= 4.8 will fail on:
/home/buildroot/autobuild/instance-2/output-1/build/openal-1.20.1/common/almalloc.cpp: In function 'void* al_malloc(size_t, size_t)':
/home/buildroot/autobuild/instance-2/output-1/build/openal-1.20.1/common/almalloc.cpp:20:45: error: 'max_align_t' is not a member of 'std'
alignment = std::max(alignment, alignof(std::max_align_t));
^
Fixes:
- http://autobuild.buildroot.org/results/589c7853ce334c7502f7cd4cdbcaaf3c6840f43b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Many of the mender CLI commands use systemctl commands to get information about
the daemon, such as the PID (IE: systemctl show -p MainPID mender-client).
As seen above, these commands expect the service file to be named
"mender-client" instead of "mender."
As such, in the current state, running a forced update check in the CLI will
result in the following error:
failed to force updateCheck: could not find the PID of the mender daemon.
Changing the name of mender.service to mender-client.service fixes the issue.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
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>
Fixes the following security issues:
CVE-2020-24332
If the tcsd daemon is started with root privileges,
the creation of the system.data file is prone to symlink attacks
CVE-2020-24330
If the tcsd daemon is started with root privileges,
it fails to drop the root gid after it is no longer needed
CVE-2020-24331
If the tcsd daemon is started with root privileges,
the tss user has read and write access to the /etc/tcsd.conf file
For details, see the advisory:
https://www.openwall.com/lists/oss-security/2020/05/20/3
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This scripts takes as entry on stdin a JSON description of the package
used for a given configuration. This description is the one generated
by "make show-info".
The script generates the list of all the packages used and if they are
affected by a CVE. The output is either a JSON or an HTML file similar
to the one generated by pkg-stats.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>=
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The affects method of the CVE uses the Package class defined in
pkg-stats. The purpose of migrating the CVE class outside of pkg-stats
was to be able to reuse it from other scripts. So let's remove the
Package dependency and only use the needed information.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add the list of the CVEs to ignore for each package because they
already have a fix for it.
This information will be useful for a cve-checker.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In 2019, the JSON vulnerability feeds switched their schema from
version 1.0 to 1.1.
The main difference is the removal of the "affects" element that we
were using to check if a package was affected by a CVE.
This information is now available in the "configuration" element which
contains the cpeid as well as properties about the versions
affected. Instead of having a list of the versions affected, with
these properties, it is possible to have a range of versions.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In order to be able to use the CVE checking logic outside of
pkg-stats, move the CVE class in a module that can be used by other
scripts.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some CVE entries in the NVD database have version_value set to "-",
which seems to indicate that it applies to all versions of the
software project, or that they don't really know which versions are
affected, and which are not.
So, for the benefit of doubt, it seems more appropriate to consider
such CVEs as affecting our packages.
This makes the total number of CVEs affecting our next branch jump
from 141 CVEs to 658 CVEs, but that number will go back down once we
switch to the JSON 1.1 schema. Indeed, in the JSON 1.0 schema, there
are often cases where a version_value is set to "=" *and* specific
versions are set to.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
