Add an upstream URL to the help text in Config.in. This
addresses the 'Missing' URL status in the package stats
web page output.
[Peter: also add URL to BR2_TOOLCHAIN_BUILDROOT_MUSL help]
Signed-off-by: Mark Corbin <mark@dibsco.co.uk>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The POSIX functions sched_getscheduler(), sched_setscheduler(),
sched_getparam(), sched_setparam() are technically not correctly
implemented by the Linux syscalls of the same name, because what the
kernel calls a PID and what POSIX calls a PID isn't truly the same,
resulting in somewhat different semantics as to what these functions
exactly apply to.
Details: https://sourceware.org/bugzilla/show_bug.cgi?id=14829
Since the musl developers put a high premium on POSIX compliance, they
deliberately implement these functions to return -ENOSYS instead of
relaying them to the respective Linux syscalls as glibc/uClibc do.
Unfortunally this breaks virtually all Linux programs using these
functions under musl. For example running 'chrt -p 1' fails with
'Function not implemented' on a musl-libc based system.
In particular, it affects embedded systems using these interfaces
for scheduling real-time processes.
As it seems unfeasible to fix all affected programs to manually use
syscall wrappers instead of the libc functions, make musl behave the
Linux way.
Signed-off-by: Stefan Nickl <Stefan.Nickl@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
News from upstream [1]:
"""
This version adds the GLOB_TILDE extension for glob, a non-stub
implementation of the catgets localization API, and posix_spawn
extensions for chdir in the child. Many arch-specific bugs are fixed,
some serious, including CVE-2019-14697 affecting several math
functions only on i386, broken riscv64 atomics, broken lseek with
large offsets on x32 and mipsn32, and broken setjmp/longjmp on mipsr6.
Various low-severity, non-arch-specific bugs are also fixed.
In addition, this release cycle sets the internal groundwork for
moving 32-bit archs to 64-bit time_t, needed for their future
viability as Y2038 approaches. Most of the changes are not externally
visible, but some affect which syscalls are used. Notably, mips64
stat-family functions can now report 64-bit file timestamps correctly,
and some time-related breakage on x32 is fixed. In addition, select no
longer stores remaining time back to the timeout argument. Previously,
whether it did so was arch-dependent and merely a consequence of the
Linux syscall behavior, which was found to be mildly non-conforming.
"""
Remove patches 0002 to 0005, which are included in the new version.
Note, that the CVE fix mentioned above is the same as patch 0004.
The license file has changed because Arm was added to the copyright
file.
[1] https://www.musl-libc.org/download.html
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes CVE-2019-14697: musl libc 1.1.23 and earlier x87 float stack imbalance
For more details, see the oss-security discussion:
https://www.openwall.com/lists/oss-security/2019/08/05/6
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add two upstream patches fixing musl vs kernel headers conflict. This
fixes build of strace for risc64 at it happens to use headers from both
sources.
Modify patch #3 to leave a single newline in user.h. Otherwise 'patch
-E' in apply-patches.sh deletes user.h instead of leaving it empty.
Fixes (strace):
http://autobuild.buildroot.net/results/ac32e83dc5eb5ce2809fc4b9d11f540dbdae9ed6/
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This version merges the RISC-V (64-bit) port and new math library
implementations of log, exp, and pow. Internals of how (non-cancellable)
syscalls are performed have been overhauled so that all code necessary to make
the syscall resides in the arch-provided header and is inlinable. In the
process, bugs in the implementation of mips and microblaze syscall mechanisms
were found and fixed. Several other bugs were fixed as well, including a
potentially serious one in the layout of static TLS for shared libraries on
archs that use "TLS variant I" layout.
A couple behaviors that were clearly undesirable but arguably mandated by POSIX
have been fixed as a result of POSIX intepretations rendering them unnecessary.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Tested-by: Mark Corbin <mark.corbin@embecosm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
>From the upstream release announcement:
"""
This release makes improvements with respect to default thread stack size,
including increasing the default from 80k to 128k, increasing the default
guard size from 4k to 8k, and allowing the default to be increased via ELF
headers so that programs that need larger stacks can be build without
source-level changes, using just LDFLAGS. Insufficient stack size for AIO
threads on kernels that don't honor the constant MINSIGSTKSZ is also fixed.
The glob core has been rewritten to fix inability to see past
searchable-but-unreadable path components, and to avoid excessive stack usage
and unnecessary syscalls. The tsearch AVL tree implementation has also been
rewritten for better size and performance. The math library adds more native
single-instruction implementations for arm, s390x, powerpc, and x86_64.
Various bugs are fixed, including several possible deadlocks, one of which was
a new regression in 1.1.20.
"""
Drop upstream patch 0002 which is included in the release.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As reported by [1], SSP support is missing in the Buildroot toolchain
for microblaze even if it's requested by selecting
BR2_TOOLCHAIN_HAS_SSP config option.
In Buildroot, we are using libssp provided by the C library (glibc,
musl, uClibc-ng) when available. We are not using libssp from gcc.
So for a microblaze glibc based toolchain, the SSP support is enabled
unconditionally by a select BR2_TOOLCHAIN_HAS_SSP.
BR2_microblazeel=y
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_KERNEL_HEADERS_4_14=y
BR2_BINUTILS_VERSION_2_30_X=y
BR2_GCC_VERSION_8_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
While building the toolchain, we are building host-binutils which
provide "as" (assembler) and host-gcc-initial wich provide a
minimal cross gcc (C only cross-compiler without any C library).
When SSP support is requested, gcc_cv_libc_provides_ssp=yes is
added to the make command line (see [2] for full details)
With this setting, the SSP support is requested but it's not available
in the end and the toochain build succeed.
When the microblaze toolchain is imported to Biuldroot (2018.05) as
external toolchain with BR2_TOOLCHAIN_EXTERNAL_HAS_SSP set, the build
stop with :
"SSP support not available in this toolchain, please disable BR2_TOOLCHAIN_EXTERNAL_HAS_SSP"
The test is doing the following command line:
echo 'void main(){}' | [...]/host/bin/microblazeel-linux-gcc.br_real -Werror -fstack-protector -x c - -o [...]/build/.br-toolchain-test.tmp
cc1: error: -fstack-protector not supported for this target [-Werror]
When we look at the gcc-final log file (config.log) we can see this
error several time when using the minimal gcc (from host-gcc-initial).
So Why the minimal gcc doesn't support SSP?
When we look at the gcc-initial log file (config.log) we can see an
error with 'as':
configure:23194: checking assembler for cfi directives
configure:23209: [...]microblazeel-buildroot-linux-gnu/bin/as -o conftest.o conftest.s >&5
conftest.s: Assembler messages:
conftest.s:2: Error: CFI is not supported for this target
conftest.s:3: Error: CFI is not supported for this target
conftest.s:4: Error: CFI is not supported for this target
conftest.s:5: Error: CFI is not supported for this target
conftest.s:6: Error: CFI is not supported for this target
conftest.s:7: Error: CFI is not supported for this target
configure:23212: $? = 1
configure: failed program was
.text
.cfi_startproc
.cfi_offset 0, 0
.cfi_same_value 1
.cfi_def_cfa 1, 2
.cfi_escape 1, 2, 3, 4, 5
.cfi_endproc
This is the only relevant difference compared to a nios2 toolchain where
libssp is enabled and available (nios2 is an example).
"CFI" stand for "Control Flow Integrity" and it seems that SSP support
requires CFI target support (see [3] for some explanation).
The SSP support seems to depends on CFI support, but the toolchain
infrastructure is not detailed enough to handle the CFI dependency.
The NiosII toolchains built with binutils < 2.30 are also affected by
this issue.
This patch improve the toolchain infrastructure by adding a new
BR2_PACKAGE_HOST_BINUTILS_SUPPORTS_CFI blind option
Disable SSP support for microblaze entirely.
Disable SSP support for nios2 only with Binutils < 2.30.
Fixes:
https://gitlab.com/free-electrons/toolchains-builder/-/jobs/72006389
[1] https://gitlab.com/free-electrons/toolchains-builder/issues/1
[2] https://git.buildroot.net/buildroot/tree/package/gcc/gcc.mk?h=2018.05#n275
[3] https://grsecurity.net/rap_faq.php
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Thomas: adjust how the BR2_PACKAGE_HOST_BINUTILS_SUPPORTS_CFI option
is expressed.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
From the upstream release announcement:
"""
This release introduces the ability to replace/interpose the allocator
(malloc) subject to certain restrictions, adds an experimental m68k
port, and makes notable improvements to stdio (application-provided
buffers), getaddrinfo (AI_ADDRCONFIG, support for IPv4-only kernel
configurations), the dynamic linker (safety against dlopen of
libraries using initial-exec TLS model, reclaiming unused memory on
FDPIC archs, better dladdr results), and handling of default thread
stack size (pthread_setattr_default_np now works more reliably).
Many bugs have been fixed, including potentially dangerous regressions
in iconv (only for new conversions to legacy encodings) and visibly
incorrect behavior in printf on non-x86 archs (%a format with
precision specifier), in getopt_long_only when short options are a
prefix for a long option, in complex arc-trig/hyperbolic functions, in
strftime and mktime (timezone-specific issues), and numerous
less-obvious places.
"""
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 1296d57918 (musl: bump to version 1.1.19) forgot to remove an
upstream patch. Do that now.
Fixes:
http://autobuild.buildroot.net/results/3ea/3ea23854c501d12aa69012df9d38d33cd10ac83c/
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Kernel version 4.15 (not 4.16 as the musl commit log claims) allows
disabling of more parts of the kernel headers definitions. Add upstream
musl patch that defines the relevant macros. This solves issues of
networking related symbols redefinition in kernel headers that cause
headers conflicts. With that in place a subsequent commit will limit the
musl/kernel headers conflict avoidance workaround in Buildroot to kernel
headers older than 4.15. This workaround has been introduced in commit
196932cd91 (toolchain: workaround musl/kernel headers conflict).
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Patch 0002-arm-atomics-asm-with-new-binutils.patch is upstream as of
commit b261a24256792177a5f0531dbb25cc6267220ca5.
Patch 0003-Makefile-include-per-arch-Makefile-before-Makefile is
upstream as of commit 45ca5d3fcb6f874bf5ba55d0e9651cef68515395.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>From the upstream announcement:
http://www.openwall.com/lists/oss-security/2017/10/19/5
Felix Wilhelm has discovered a flaw in the dns response parsing for
musl libc 1.1.16 that leads to overflow of a stack-based buffer.
Earlier versions are also affected.
When an application makes a request via getaddrinfo for both IPv4 and
IPv6 results (AF_UNSPEC), an attacker who controls or can spoof the
nameservers configured in resolv.conf can reply to both the A and AAAA
queries with A results. Since A records are smaller than AAAA records,
it's possible to fit more addresses than the precomputed bound, and a
buffer overflow occurs.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
New binutils (since 2.27.51) cannot build musl-1.1.16 due to breakage in ARMv4
atomics asm. This patch from upstream musl repository is needed until
musl-1.1.17 is released:
https://git.musl-libc.org/cgit/musl/commit/?id=b261a24256792177a5f0531dbb25cc6267220ca5
Signed-off-by: Timothy Lee <timothy.ty.lee@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The check-package script when ran gives warnings on ordering issues
on all of these Config files. This patch cleans up all warnings
related to the ordering in the Config files for packages starting with
the letter m in the package directory.
The appropriate ordering is: type, default, depends on, select, help
See http://nightly.buildroot.org/#_config_files for more information.
Signed-off-by: Adam Duskett <Adamduskett@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes:
CVE-2016-8859 - fixes a serious under-allocation bug in regexec due to
integer overflow.
Drop upstream patch.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
musl provides neither sys/queue.h nor sys/cdefs.h. Those two headers are
however quite widely used in a lot of packages (though they should at
least not use cdefs.h which is only full of mostly-legacy macros, and
which is mostly an internal header of glibc and was never really meant to
be exposed to, and used by packages).
But we don't live in an ideal world, so a lot of packages break when
those two headers are missing.
We already took care of sys/queue.h with the netbsd-queue package. But
the need for cdefs.h is getting more and more pressing.
We rename the netbsd-queue package into musl-compat-headers, and we
make it install sys/queue.h (from NetBSD) and sys/cdefs.h (a minimalist
one we bundle in Buildroot). We can't use the cdefs.h from NetBSD
because it includes machine-dependent headers; instead we bundle a very
minimalistic one, that covers only what we need.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Don't enable SSP support on external toolchains just because they use
glibc or musl. Instead of that, make the external toolchains explictily
declare if they support SSP or not. And also add a check to detect SSP
support when using custom external toolchains.
For internal toolchains we always enable SSP support for glibc and musl.
Fixes:
http://autobuild.buildroot.net/results/ac7c9b3ad2e52abfe6b79a80045e4218eeb87175/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
[Thomas:
- remove uClibc-specific SSP check, since there is now a generic
check being done.
- send potential compilation errors caused by the SSP check to
oblivion, in order to avoid causing confusion for the user.
- add autobuilder reference.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Building the musl C library on Thumb (Thumb1, not Thumb2), fails with:
{standard input}:20: Error: only lo regs allowed with immediate -- `mov fp,#0'
{standard input}:21: Error: only lo regs allowed with immediate -- `mov lr,#0'
{standard input}:25: Error: unshifted register required -- `and ip,a1,#-16'
Since there are no cores that we support that are Thumb1 only, use the
same solution as the one used by glibc: build the C library in ARM
mode.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As pointed in http://www.openwall.com/lists/musl/2016/02/17/3 add the
fwrite regression patch for the recent 1.1.13 release.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Select that package from musl, too, since it is a dependency.
Fixes:
http://autobuild.buildroot.org/results/15c/15c9a80fb2754ed1866b59d5e62d02691b57834e/
... and numerous similar issues ...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Sergio Prado <sergio.prado@e-labworks.com>
Cc: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that we check that a target package in the _DEPENDENCIES of another
package has to be enabled in config, all target packages must have a
kconfig symbol.
Add a Kconfig symbol for linux-headers, and select it from the packages
that depends on it (C libraries).
Also remove the now-misleading comments "for legal-info" from the C
libraries.
Fixes:
http://autobuild.buildroot.org/results/2a9/2a9e5d27b34357819b44f573a834da1ba5079030/
... and numerous similar failures ...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Musl does not provide a 'sys/queue.h' implementation, and this has been
a problem for packages that depend on it.
So lets create a package called netbsd-queue that will install a
'sys/queue.h' in the staging directory when enabled, based on the
NetBSD implementation.
Musl toolchain and external toolchain packages will depend on this
package, so that 'sys/queue.h' will be always installed when compiling
with a musl based toolchain.
Tested on ARM and x86 in the following cases:
- Buildroot musl toolchain.
- External musl toolchain without 'sys/queue.h'.
- External musl toolchain with 'sys/queue.h'.
Fixes:
http://autobuild.buildroot.net/results/24bad2d06ab40024dacf136bee722072d587f84e
And possibly many others.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
External toolchain use requires a static libc (as buildroot uses
`gcc --print-file-name libc.a` to find the sysroot); thus, the static portion
of a musl build should not be conditional.
Signed-off-by: Charles Duffy <chaduffy@cisco.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: use SHARED_STATIC_LIBS_OPTS to simplify the logic.]
Signed-off-by: Charles Duffy <chaduffy@cisco.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Using the config option '--libdir=/lib' makes the setting of prefix to an
empty path obsolete in MUSL_INSTALL_TARGET_CMDS.
Signed-off-by: Jörg Krause <jkrause@posteo.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Set the installation path for the libraries to /lib instead of /usr/lib.
This fixes an issue when building a toolchain with the musl library by
the internal toolchain backend of Buildroot in the first step and import this
toolchain later as a custom external toolchain in a second step. For this use
case check-musl in toolchain/helpers.mk failed because it did not find the
libc or libm in sysroot/lib.
This patch superseeds: [PATCH 1/1] toolchain/helpers.mk: fix check-musl
http://patchwork.ozlabs.org/patch/417587/
Signed-off-by: Jörg Krause <jkrause@posteo.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Without this, including libstdc++'s <cstddef> fails.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
After switching to a two stage gcc solution, there is no longer a need
to do weird things in the musl build, with certain things being done
twice (MUSL_CONFIGURE_CALL). Now the MUSL_CONFIGURE_CMDS variable only
does the configuration, and the MUSL_BUILD_CMDS only does the build,
as it should be.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, the internal toolchain backend does a three stage gcc
build, with the following sequence of builds:
- build gcc-initial
- configure libc, install headers and start files
- build gcc-intermediate
- build libc
- build gcc-final
However, it turns out that this is not necessary, and only a two stage
gcc build is needed. At some point, it was believed that a three stage
gcc build was needed for NPTL based toolchains with old gcc versions,
but even a gcc 4.4 build with a NPTL toolchain works fine.
So, this commit switches the internal toolchain backend to use a two
stage gcc build: just gcc-initial and gcc-final. It does so by:
* Removing the custom dependency of all C libraries build step to
host-gcc-intermediate. Now the C library packages simply have to
depend on host-gcc-initial as a normal dependency (which they
already do), and that's it.
* Build and install both gcc *and* libgcc in
host-gcc-initial. Previously, only gcc was built and installed in
host-gcc-initial. libgcc was only done in host-gcc-intermediate,
but now we need libgcc to build the C library.
* Pass appropriate environment variables to get SSP (Stack Smashing
Protection) to work properly:
- Tell the compiler that the libc will provide the SSP support, by
passing gcc_cv_libc_provides_ssp=yes. In Buildroot, we have
chosen to use the SSP support from the C library instead of the
SSP support from the compiler (this is not changed by this patch
series, it was already the case).
- Tell glibc to *not* build its own programs with SSP support. The
issue is that if glibc detects that the compiler supports
-fstack-protector, then glibc uses it to build a few things with
SSP. However, at this point, the support is not complete (we
only have host-gcc-initial, and the C library is not completely
built). So, we pass libc_cv_ssp=no to tell the C library to not
use SSP support itself. Note that this is not a big loss: only a
few parts of the C library were built with -fstack-protector,
not the entire library.
* A special change is needed for ARC, because its libgcc depends on
the C library, which breaks building libgcc in
host-gcc-initial. This looks like a bug in the ARC compiler, as it
does not obey the inhibit_libc variable which tells the compiler
build process to *not* enable things that depend on the C
library. So for now, in host-gcc-initial, we simply disable the
build of libgmon.a for ARC. It's going to be built as part of
host-gcc-final, so the final compiler will have gmon support.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
