Project:Musl

Project Description
The Hardened musl subproject has a goal similar to its sister subproject, Hardened uClbic, but with the intention of using musl to replace glibc as the system's "C standard library," or "libc" for short. 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 indireclty incorporated into statically linked executables. For embedded systems, the size and speed of your libc become important issues which are better addressed by libc's 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 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. Since there are different advantages for different folks, in Gentoo we attempt to target everything: all arches, all libc, hardened/vanilla userland, and hardened/vanilla Linux kernel.

musl's completeness, including a robust implementation of NPTL, means that we can include all of Gentoo's Hardened toolchain goodies without any problems:


 * stack smashing protection ( ssp ), which requires NPTL
 * position independent execution ( pie)
 * bind now and relro, linker hardening to protect the global offset table

These are augmented by the kernel hardening, especially PaX 's enhanced address space layout randomization ( aslr ).

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.

Project Goals
The project goals can be best summarized by the following chart:


 * Yes = completed
 * Not Yet = in progress
 * No = no plans
 * NA = not applicable
 * stage3 = catalyst built stages 1, 2 and 3 available (ideal)
 * stage4 = manually built minimal system
 * livecd = minimal (installation) live CD
 * desktop = manually built full desktop system

Working with musl
Unlike the situation with uClibc, where pretty much every package in the Gentoo portage tree "just works," musl's adherence to standards means that many packages need some patching. Most of this is minor, like the location of header files, but some is more substantial and must address

0) Get your chroot ready as you would on any other stage3. See the Gentoo Handbook.

1) Set up your favorite GENTOO_MIRRORS and SYNC, then sync, by doing the following:

echo GENTOO_MIRRORS=ftp://192.168.3.1/pub/gentoo >> /etc/portage/make.conf echo SYNC=rsync://192.168.3.1/portage >> /etc/portage/make.conf emerge --sync

2) Set up your nameserver for DNS resolution:

echo nameserver 192.168.3.1 >> /etc/resolv.conf

3) We need to get git in order to add the overlay. Unfortunately, right now we can't build git with gnupg support so do the following:

echo "dev-vcs/git -gpg" >> /etc/portage/package.use echo "dev-vcs/git libintl.conf" >> /etc/portage/package.env emerge -q layman dev-vcs/git

4) Let's add the overlay. layman is still a bit stupid, so we have to manually switch to the musl branch:

layman -L layman -a hardened-development cd /var/lib/layman/hardened-development && git checkout musl echo source /var/lib/layman/make.conf >> /etc/portage/make.conf

5) Okay 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 -uvNDq world

6) In the future, update both the portage tree and the overlay before repeating step 5.

emerge --sync layman -S emerge -uvNDq world

I Want to Participate
To participate in the Hardened musl project join the mailing list at  and visit our online IRC channel at   on.