Skip to content
  1. Jun 04, 2020
  3. Jun 03, 2020
  5. Jun 02, 2020
  7. Jun 01, 2020
  9. May 31, 2020
    • Romain Naour's avatar
      package/qemu: bump to 5.0.0 · 4675c7d4
      Romain Naour authored 
      Remove upstream patches [1][2].

Switch to libcap-ng for virtio support [3].

Remove bluez option [4].

Disable container build [5] since we don't want to use containers for cross-building.

Disable io_uring [6] since there is no such package in Buildroot (yet).

The ARM Cortex-m7 cpu is now supported [7] a defconfig can be added in follup patch.

[1] https://git.qemu.org/?p=qemu.git;a=commit;h=00b5032eaddb7193f03f0a28b10286244d2e2a7b
[2] https://git.qemu.org/?p=qemu.git;a=commit;h=21bf9b06cb6d07c6cc437dfd47b47b28c2bb79db
[3] https://git.qemu.org/?p=qemu.git;a=commit;h=7e46261368d129c5ee8be927f5bcadc7ecd800d7
[4] https://git.qemu.org/?p=qemu.git;a=commit;h=1d4ffe8dc77cbc9aafe8bcf514ca0e43f85aaae3
[5] https://git.qemu.org/?p=qemu.git;a=commit;h=afc3a8f9f1df09c091f9903eaef82b35c152cacf
[6] https://git.qemu.org/?p=qemu.git;a=commit;h=c10dd8565defdb14695580c9369b20f4544e65a2
[7] https://git.qemu.org/?p=qemu.git;a=commit;h=cf7beda5072e106ddce875c1996446540c5fe239

See:
https://wiki.qemu.org/ChangeLog/5.0
https://www.qemu.org/2020/04/29/qemu-5-0-0/



Signed-off-by: default avatarRomain Naour <romain.naour@gmail.com>
Cc: Adam Duskett <aduskett@gmail.com>
Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@bootlin.com>
      4675c7d4
    • Romain Naour's avatar
      package/qemu: remove csky fork · 20f45029
      Romain Naour authored 
      We have a qemu fork for csky cpus [1] but since qemu version
bump to 4.2.0 [2] and libssh2/libssh change the csky build is
broken.

The csky fork is based on Qemu 3.0.0 but unlike autotools packages
any unknown option is handled as error.

Since we don't want to support all options from previous qemu
release and the github repository has been removed [3] and the
only remaining archive is located on http://sources.buildroot.net,
remove the qemu csky fork as suggested by [4].

[1] https://git.buildroot.net/buildroot/commit/?id=f816e5b276f1ef15840bec6667f1e8219717ab7d
[2] https://git.buildroot.net/buildroot/commit/?id=0ea17054ce7dfc54efca5634133cef786445e7b1
[3] https://github.com/c-sky/qemu
[4] http://lists.busybox.net/pipermail/buildroot/2020-May/281885.html



Signed-off-by: default avatarRomain Naour <romain.naour@gmail.com>
Cc: Guo Ren <ren_guo@c-sky.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
[Peter: move patches out of 4.2.0 subdir]
Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      20f45029
    • Romain Naour's avatar
      package/libcap-ng: add host variant · b4cc1fc0
      Romain Naour authored 
      Qemu 5.0.0 recently switched to libcap-ng [1].
Add the host variant for host-qemu package.

[1] https://git.qemu.org/?p=qemu.git;a=commit;h=7e46261368d129c5ee8be927f5bcadc7ecd800d7



Signed-off-by: default avatarRomain Naour <romain.naour@gmail.com>
Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@bootlin.com>
      b4cc1fc0
    • Yann E. MORIN's avatar
      package/linux-tools/perf: bear the kernel options munging · 5587f366
      Yann E. MORIN authored 
      

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: default avatarYann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@bootlin.com>
      5587f366
    • Yann E. MORIN's avatar
      package/linux-headers: add support for CIP kernel versions with same-as-kernel · d25a5724
      Yann E. MORIN authored 
      When the linux-headers are configured to use the same source as the
kernel (BR2_KERNEL_HEADERS_AS_KERNEL), and the kernel is configured
to be one of the two CIP versions (BR2_LINUX_KERNEL_LATEST_CIP_VERSION
or BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION), the build fails if the
kernel sources are not already downloaded:

    $ cat defconfig
    BR2_LINUX_KERNEL=y
    BR2_LINUX_KERNEL_LATEST_CIP_VERSION=y
    $ make defconfig BR2_DEFCONFIG=$pwd)/defconfig
    $ make linux-headers-source

    >>> linux-headers 4.19.118-cip25 Downloading
    --2020-05-13 19:28:44--  https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.118-cip25.tar.xz


    Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:1d::432, 151.101.121.176
    Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:1d::432|:443... connected.
    HTTP request sent, awaiting response... 404 Not Found
    2020-05-13 19:28:45 ERROR 404: Not Found.

    make[1]: *** [package/pkg-generic.mk:171: /home/ymorin/dev/buildroot/O/build/linux-headers-4.19.118-cip25/.stamp_downloaded] Error 1
    make: *** [Makefile:23: _all] Error 2

We fix that by adding yet another duplication of information out of
the linux.mk, to use the CIP-specific git tree where to get the
archives as snapshots.

Signed-off-by: default avatarYann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@bootlin.com>
      d25a5724
    • Yann E. MORIN's avatar
      linux: forcibly disable use of gcc plugins · 40e0bf4c
      Yann E. MORIN authored 
      

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: default avatarGanesh <ganesh45in@gmail.com&gt;,>
Reported-by: default avatarHeiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: default avatarYann 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: default avatarHeiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@bootlin.com>
      40e0bf4c
    • Romain Naour's avatar
      package/qt5/qt5webengine: don't link with libstdc++.a on the host · f9548114
      Romain Naour authored 
      While cross-compiling, qt5webengine is building a host tool, 'gn', and
by default wants to link it statically with libstdc++, when the tool is
otherwise dynamically linked with other libraries:

    $ ldd 3rdparty/gn/out/Release/gn
        linux-vdso.so.1 (0x00007ffc1c999000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f48a3c06000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f48a3be4000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f48a3a1b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f48a3c53000)

Not all ditributions have the static libraries installed by default; for
example, on Fedora, libstdc++-static is not installed on a fresh system,
leading to build issues:

  [185/185] LINK gn
  FAILED: gn
  /usr/bin/g++ -O3 -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-strip-all -Wl,--as-needed -static-libstdc++ -pthread -o gn -Wl,--start-group tools/gn/gn_main.o base.a gn_lib.a -Wl,--end-group -ldl
  /usr/bin/ld : unable to find -lstdc++
  [...]
  Project ERROR: GN build error!

The root cause is the addition in [0] of a command line option to the
build of gn, that requests static linking with libstdc++ by default.

Explicitly pass that option now, to avoid static linking with libstdc++
and get a fully dynamicallty linked executable:

    $ ldd 3rdparty/gn/out/Release/gn
        linux-vdso.so.1 (0x00007ffd3f160000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f68138e7000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f68138c5000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f68136fc000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f68135b6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6813b13000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f681359c000)

[0] https://github.com/qt/qtwebengine-chromium/commit/cfab9198a9917f42cf08b1caf84ab9b71aac1911#diff-905c8f054808213577c0a92d1b704615



Signed-off-by: default avatarRomain Naour <romain.naour@gmail.com>
Cc: Gaël Portay <gael.portay@collabora.com>
[yann.morin.1998@free.fr:
  - rewrite the commit log with extra details and explanations
]
Signed-off-by: default avatarYann E. MORIN <yann.morin.1998@free.fr>
      f9548114
    • Romain Naour's avatar
      package/gcc/9.3.0: fix host-gcc-final when ccache is used · 58ecbbc3
      Romain Naour authored 
      As reported by several Buildroot users [1][2][3], the gcc build
may fail while running selftests makefile target.

The problem only occurs when ccache is used with gcc 9 and 10,
probably due to a race condition.

While debuging with "make -p" we can notice that s-selftest-c target
contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4].

  s-selftest-c: cc1

While the build is failing, the s-selftest-c dependencies recipe is
still running and reported as a bug by make.

  "Dependencies recipe running (THIS IS A BUG)."

A change [5] in gcc 9 seems to introduce the problem since we can't
reproduce this problem with gcc 8.

As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before
including language makefile fragments.

With the fix applied, the s-seltest-c dependency contains
SELFTEST_DEPS value.

  s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests

[1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html
[2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html
[3] https://github.com/cirosantilli/linux-kernel-module-cheat/issues/108
[4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120
[5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502
[6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html



Signed-off-by: default avatarRomain Naour <romain.naour@gmail.com>
Cc: Ben Dakin-Norris <ben.dakin-norris@navtechradar.com>
Cc: Maxim Kochetkov <fido_max@inbox.ru>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: default avatarYann E. MORIN <yann.morin.1998@free.fr>
      58ecbbc3
    • Heiko Thiery's avatar
      package/sysrepo: fix SysV init script · 1a14a838
      Heiko Thiery authored 
      

The current script (S51sysrepo-plugind) is not able to stop the daemon.

Possible options to fix the problem:

A) By adding the "-m -p $PIDFILE" option to start the pid file will be
   created but it will not contain the correct PID used by the daemon.
   This is obviously because the daemon forks.
B) By not starting the daemon in background (sysrepo-plugind -d) and
   let do it by start-stop-daemon with "-b" option. But then the log
   messages of the daemon will not longer ends in the syslog but to stderr.
C) Start the daemon without a pidfile and stop the daemon with the
   "-x" option.

The only valid option is C to fix that.

Signed-off-by: default avatarHeiko Thiery <heiko.thiery@gmail.com>
[yann.morin.1998@free.fr: introduce EXECUTABLE]
Signed-off-by: default avatarYann E. MORIN <yann.morin.1998@free.fr>
      1a14a838
    • Carlos Santos's avatar
      DEVELOPERS: remove Carlos Santos · ae417368
      Carlos Santos authored 
      

Goodbye!

Signed-off-by: default avatarCarlos Santos <unixmania@gmail.com>
Signed-off-by: default avatarYann E. MORIN <yann.morin.1998@free.fr>
      ae417368
    • Fabrice Fontaine's avatar
      package/xen: security bump to version 4.13.1 · 0caabc8c
      Fabrice Fontaine authored 
      - Fix CVE-2020-11739: An issue was discovered in Xen through 4.13.x,
allowing guest OS users to cause a denial of service or possibly gain
privileges because of missing memory barriers in read-write unlock
paths. The read-write unlock paths don't contain a memory barrier. On
Arm, this means a processor is allowed to re-order the memory access
with the preceding ones. In other words, the unlock may be seen by
another processor before all the memory accesses within the "critical"
section. As a consequence, it may be possible to have a writer executing
a critical section at the same time as readers or another writer. In
other words, many of the assumptions (e.g., a variable cannot be
modified after a check) in the critical sections are not safe anymore.
The read-write locks are used in hypercalls (such as grant-table ones),
so a malicious guest could exploit the race. For instance, there is a
small window where Xen can leak memory if XENMAPSPACE_grant_table is
used concurrently. A malicious guest may be able to leak memory, or
cause a hypervisor crash resulting in a Denial of Service (DoS).
Information leak and privilege escalation cannot be excluded.

- Fix CVE-2020-11740: An issue was discovered in xenoprof in Xen through
4.13.x, allowing guest OS users (without active profiling) to obtain
sensitive information about other guests. Unprivileged guests can
request to map xenoprof buffers, even if profiling has not been enabled
for those guests. These buffers were not scrubbed.

- Fix CVE-2020-11741: An issue was discovered in xenoprof in Xen through
4.13.x, allowing guest OS users (with active profiling) to obtain
sensitive information about other guests, cause a denial of service, or
possibly gain privileges. For guests for which "active" profiling was
enabled by the administrator, the xenoprof code uses the standard Xen
shared ring structure. Unfortunately, this code did not treat the guest
as a potential adversary: it trusts the guest not to modify buffer size
information or modify head / tail pointers in unexpected ways. This can
crash the host (DoS). Privilege escalation cannot be ruled out.

- Fix CVE-2020-11742: An issue was discovered in Xen through 4.13.x,
allowing guest OS users to cause a denial of service because of bad
continuation handling in GNTTABOP_copy. Grant table operations are
expected to return 0 for success, and a negative number for errors. The
fix for CVE-2017-12135 introduced a path through grant copy handling
where success may be returned to the caller without any action taken. In
particular, the status fields of individual operations are left
uninitialised, and may result in errant behaviour in the caller of
GNTTABOP_copy. A buggy or malicious guest can construct its grant table
in such a way that, when a backend domain tries to copy a grant, it hits
the incorrect exit path. This returns success to the caller without
doing anything, which may cause crashes or other incorrect behaviour.

- Fix CVE-2020-11743: An issue was discovered in Xen through 4.13.x,
allowing guest OS users to cause a denial of service because of a bad
error path in GNTTABOP_map_grant. Grant table operations are expected to
return 0 for success, and a negative number for errors. Some misplaced
brackets cause one error path to return 1 instead of a negative value.
The grant table code in Linux treats this condition as success, and
proceeds with incorrectly initialised state. A buggy or malicious guest
can construct its grant table in such a way that, when a backend domain
tries to map a grant, it hits the incorrect error path. This will crash
a Linux based dom0 or backend domain.

https://xenproject.org/downloads/xen-project-archives/xen-project-4-13-series/xen-project-4-13-1



Signed-off-by: default avatarFabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: default avatarYann E. MORIN <yann.morin.1998@free.fr>
      0caabc8c
    • Fabrice Fontaine's avatar
      package/mp4v2: fix build with gcc <= 5 · 9b911475
      Fabrice Fontaine authored 
      Fixes:
 - http://autobuild.buildroot.org/results/14937c96a82fb3d10e5d83bd7b2905b846fb09f9



Signed-off-by: default avatarFabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: expand the patch' commit log]
Signed-off-by: default avatarYann E. MORIN <yann.morin.1998@free.fr>
      9b911475
  11. May 30, 2020