|Description||This subproject aims to port the hardened tool chain to musl based systems for a variety of architectures. The project treats musl as an alternative to glibc and uClibc, and not necessarily as "embedded".|
|IRC channel||#gentoo-hardened (webchat)|
Last elected: 2019-08-27
(and inherited member(s))
A system's libc forms an integral part of the toolchain, but unlike the other components, it remains a runtime dependency of nearly every dynamically linked object in the system, or becomes incorporated into statically linked executables.
For embedded systems, the size and speed of your libc become important issues which are better addressed by libcs designed with that purpose in mind. uClibc addresses at least the size issue by being very configurable, so any unneeded code can be turned off. Whether a function is required by POSIX standards or not doesn't matter if you are not using it for some targetted application. musl takes a different approach: it is written with static linking in mind, but also with fast dynamic linking capabilities, while remaining close to standards and conscious of security issues. However, unlike uClibc, it is not configurable. How glibc, uClibc and musl compare on the various points of interest is complex and something that will probably be debated forever.
The musl team does provide a table of C/POSIX standard library implementations for Linux that you can browse.
Since there are different needs for different folks, in Gentoo we are not afraid to target anything and everything: all arches, all libcs, hardened/vanilla userland, hardened/vanilla Linux kernel, and even different kernels.
- Stack Smashing Protection (SSP), which requires threads but doesn't work with the old NPTL or LinuxThreads that uClibc provides.
- Position Independent Execution (PIE).
- Bind now and relro, linker hardening to protect the global offset table.
This subproject aims to treat musl more as a drop in alternative to glibc, and not necessarily as "embedded". This is not at the exclusion of the concerns of embedded systems, but rather to make our userland tarballs as flexible as possible. They can be used as development environments for native compiling on native hardware, starting points to build server or desktop systems, or they can be stripped down to just the essential apps for whatever purpose. The stages are not "embedded" in the sense that they use busybox as their "Swiss Army Knife" of common UNIX utilities. While not excluding this possibility, we aim at making most (all?) of Gentoo's packages both hardened and musl compatible.
The project goals can be best summarized by the following chart:
|Arch||Subarchs||Tool Chain Hardening||Status||Downloads|
|ppc64||ppc64/ppc64le||Yes||Development||stage3-ppc64-musl-hardened-openrc / stage3-ppc64le-musl-hardened-openrc|
Working with musl
Unlike the situation with uClibc, where pretty much every package in the Gentoo portage tree "just builds," musl's adherence to standards means that many packages which deviate from those standards, primarily POSIX, need some patching. Most of this is minor, like the location of header files, but some is more substantial. So we maintain the musl overlay to house those patches, and this overlay must be added to the stage3's to be able to update and maintain them. Here's how:
1) Get the chroot ready just as in any other stage 3. See the Handbook.
2) Sync the main ebuild repository:
3) Install git to fetch the overlay and eselect-repository to setup the overlay:
emerge --ask app-eselect/eselect-repository dev-vcs/git
4) Let's add the overlay.
eselect repository enable musl
5) Now we can update! If we tried to update without the overlay, we get a bunch of downgrades to ebuilds that are slightly broken on musl and will not build.
emerge -uvDU @world
The following people are or have contributed to the project: