from Wikipedia
| musl | |
|---|---|
 | |
| Developers | Rich Felker (dalias) and others |
| Initial release | February 11, 2011[1] |
| Stable release | 1.2.5[2]
/ February 29, 2024 |
| Repository | |
| Operating system | Linux 2.6 or later |
| Platform | x86, x86_64, ARM, loongarch64, MIPS, Microblaze, PowerPC, powerpc64, x32, RISC-V, OpenRISC, s390x, SuperH |
| Type | |
| License | MIT License |
| Website | musl.libc.org |
musl is a C standard library intended for operating systems based on the Linux kernel, released under the MIT License.[3] It was developed by Rich Felker to write a clean, efficient, and standards-conformant libc implementation.[4]
Overview
[edit]musl was designed from scratch to allow efficient static linking and to have realtime-quality robustness by avoiding race conditions, internal failures on resource exhaustion, and various other bad worst-case behaviors present in existing implementations.[4] The dynamic runtime is a single file with stable ABI allowing race-free updates and the static linking support allows an application to be deployed as a single portable binary without significant size overhead.
It claims compatibility with the POSIX 2008 specification and the C11 standard. It also implements most of the widely used non-standard Linux, BSD, and glibc functions.[5] There is partial ABI compatibility with the part of glibc required by Linux Standard Base.[6]
Version 1.2.0 has support for (no longer current) Unicode 12.1.0 (while still having full UTF-8 support,[7] more conformant/strict than glibc), and version 1.2.1 "features the new 'mallocng' malloc implementation, replacing musl's original dlmalloc-like allocator that suffered from fundamental design problems."[2]
Use
[edit]Linux distributions which use musl as their standard C library (some use only musl) include but are not limited to:
- Alpine Linux[8]
- Dragora 3[9]
- Gentoo Linux (glibc by default, musl can be chosen at install time)[10]
- OpenWrt[11]
- postmarketOS[12]
- Sabotage[13]
- Morpheus Linux[14]
- Chimera Linux[15]
- Void Linux[16]
- KISS Linux
- ^ "musl - obsolete versions". musl-libc.org. 2017-10-31. Retrieved 2018-01-14.>
- ^ a b "musl libc Release History". musl.libc.org. Archived from the original on 2021-10-16. Retrieved 2020-08-13.
- ^ Rich Felker; et al. (2016-04-29). "COPYRIGHT". Archived from the original on 2021-10-16. Retrieved 2016-09-26.
- ^ a b "Introduction to musl". 2016-04-21. Archived from the original on 2021-10-16. Retrieved 2016-09-26.
- ^ "Compatibility". wiki.musl-libc.org. 2014-05-27. Archived from the original on 2021-10-16. Retrieved 2016-09-26.
- ^ "Comparison of C/POSIX standard library implementations for Linux". www.etalabs.net. Archived from the original on 2021-10-16.
- ^ "musl libc - Functional differences from glibc". wiki.musl-libc.org. Archived from the original on 2021-10-16. Retrieved 2020-08-13.
- ^ "About". Alpine Linux. Retrieved 18 June 2022.
- ^ Larabel, Michael (30 September 2018). "Dragora 3.0 Alpha 2 Released As One Of The Libre GNU/Linux Platforms". Phoronix. Phoronix Media. Retrieved 18 June 2022.
- ^ Gentoo Authors (20 July 2021). "Additional stage downloads for amd64, ppc, x86, arm available". Gentoo Linux. Retrieved 18 June 2022.
- ^ Fietkau, Felix (16 Jun 2015). "OpenWrt switches to musl by default". Archived from the original on 28 July 2015.
- ^ "About postmarketOS - postmarketOS Wiki". wiki.postmarketos.org. Retrieved 2024-08-07.
- ^ README.md on GitHub
- ^ "morpheus". Archived from the original on 2021-10-16. Retrieved 2018-06-15.
- ^ "Chimera Linux - About". Chimera Linux. Retrieved 2023-05-10.
- ^ "Enter the void". Void Linux. Retrieved 18 June 2022.
The seL4 microkernel[1] ships with musl.
For binaries that have been linked against glibc, gcompat and[2] glibmus-hq[3] can be used to execute them on musl-based distros.
See also
[edit]
References
[edit]- ^ seL4/musllibc, seL4 microkernel and related repositories, 2020-08-30, archived from the original on 2021-10-16, retrieved 2020-09-05
- ^ "Adélie Linux / gcompat". GitLab. Archived from the original on 2021-10-16. Retrieved 2019-10-21.
- ^ "Manoel-linux-gitlab / GlibMus-HQ · GitLab".
External links
[edit]- Official website
- Comparison of C/POSIX standard library implementations for Linux
- Matrix of C/POSIX standard libraries by architecture
- Project:Musl on Gentoo wiki
| Features | |||||
|---|---|---|---|---|---|
| Standard library |
| ||||
| Compilers | |||||
| IDEs | |||||
| Comparison with other languages | |||||
| Descendant languages | |||||
| Designer | |||||
from Grokipedia
Introduction
Overview
musl is a lightweight implementation of the C standard library for Linux-based systems, providing standards-compliant interfaces for ISO C and POSIX functionality built directly on the Linux system call API.[2] It serves as the core runtime library for C programs, offering essential services such as memory allocation, file I/O, threading, and networking, while emphasizing simplicity and minimal resource usage.[2] Developed by Rich Felker, musl was first released in 2011 as a new general-purpose C library option.[2][9] The project prioritizes correctness in standards conformance and efficiency, enabling compact binaries suitable for a range of environments from embedded devices to servers.[2] As open-source software licensed under the permissive MIT License, musl encourages widespread adoption and modification by developers and distributions.[2]Purpose and Goals
musl was developed as a lightweight implementation of the C standard library for Linux systems, with the primary goal of providing a clean, efficient, and fully standards-conformant alternative to existing libraries. It aims to deliver ISO C and POSIX functionality with minimal dependencies, avoiding bloat and unnecessary complexity to ensure correctness in terms of standards conformance and safety. By prioritizing simplicity in design, musl seeks to produce optimal code size and reasonable performance across a range of environments, from embedded devices to servers.[10][2] The creation of musl was motivated by the shortcomings of glibc, which suffers from excessive complexity, resource leaks, and issues with dynamic linking that complicate deployment, and uClibc, which offers limited standards compliance and incomplete POSIX support. These limitations made existing libraries unsuitable for embedded systems, static-linked applications, and security-sensitive contexts where predictability and auditability are essential. musl addresses these by focusing on a lean architecture that eliminates vendor-specific extensions and reduces the risk of race conditions or deployment surprises.[2][10] A key objective of musl is to enable straightforward static linking, producing reproducible binaries that operate without runtime dependencies or unexpected behavior, thereby enhancing portability across architectures and improving overall system reliability. This emphasis on auditability and minimal overhead supports its use in environments requiring high robustness, such as real-time applications, while maintaining first-class support for features like UTF-8 locales.[11][2]History
Origins and Early Development
The development of musl traces its roots back to 2005, when Rich Felker, known online as dalias, began experimenting with lightweight alternatives to existing C standard library implementations as a student.[12] Felker, who would become the primary developer and maintainer of musl, was driven by dissatisfaction with the dominant options at the time, particularly glibc's emphasis on dynamic linking as a core design principle, which made static linking an afterthought, and uClibc's limitations in standards compliance and completeness for broader use cases.[13][2] From these early explorations, Felker pursued a vision of building a new libc from scratch, prioritizing correctness, simplicity, and resource efficiency over incremental improvements to legacy codebases.[2] This approach aimed to address gaps in specification adherence and safety features, such as robust mutex handling and thread cancellation, that were inadequately supported in glibc and uClibc.[2] The project remained in private development for several years, allowing Felker to refine core concepts without external pressures, focusing on a clean implementation tailored for both embedded systems and general-purpose Linux environments. In 2011, after six years of solitary work, Felker named the project "musl"—pronounced like "mussel" or "muscle"—and released its first public version, marking the transition from experimentation to an open-source endeavor.[2] Initial community engagement occurred through the musl mailing list, where early discussions included patches, compatibility questions with older toolchains, and feedback on syscall wrappers, helping shape the library's foundational stability.[14]Release Timeline
The first stable release of musl, version 1.0.0, occurred on March 20, 2014, marking the culmination of three years of development and extensive testing to establish it as a production-ready alternative to existing C libraries for Linux systems.[7] This milestone emphasized correctness, standards compliance, and support for static linking, with subsequent minor updates in the 1.0 series—such as 1.0.1 on April 16, 2014, and 1.0.5 on March 30, 2015—focusing on critical bug fixes, including floating-point printf issues, buffer overflows like CVE-2014-3484, and compatibility enhancements for architectures like MIPS soft-float ABI.[7] These early releases prioritized stability over new features, addressing foundational issues to build user trust. The 1.1 series began with version 1.1.0 on April 16, 2014, introducing bootstrap improvements such as out-of-tree builds, RELRO memory protection, and enhanced malloc capabilities to facilitate easier integration and deployment in diverse environments.[7] Key milestones in this series included IPv6 enhancements, like improved VDSO support for clock functions, and new architecture ports such as AArch64 in 1.1.7 (March 18, 2015), alongside security fixes for issues like CVE-2015-1817 in 1.1.8.[7] By 1.1.23 on July 16, 2019, the series had incorporated features like RISC-V (64-bit) support and GLOB_TILDE for globbing (added in 1.1.24 on October 13, 2019), with changelogs consistently highlighting bug fixes, POSIX compatibility, and performance tweaks for threading and dynamic linking to maintain a focus on reliability.[7] Version 1.2.0 arrived on February 20, 2020, as a significant update transitioning all 32-bit architectures to 64-bit time_t to avert the Year 2038 problem, enabling representation of dates beyond January 2038 without kernel changes.[7] Subsequent releases in the 1.2 series addressed security vulnerabilities, such as buffer overflows in 1.2.2 (January 15, 2021, fixing CVE-2020-28928).[7] Notable advancements included the mallocng allocator in 1.2.1 (August 4, 2020) for better performance and DNSSEC support, while 1.2.5 on February 29, 2024, added support for statx syscall, clone3, and new ports like loongarch64 and riscv32, with ongoing patches in the 1.2.x series through 2025 emphasizing compatibility and bug resolution.[7] Version 1.2.6, released in mid-2025, included fixes for security issues such as CVE-2025-26519 (out-of-bounds write in iconv). As of November 2025, the 1.2.x branch continues with security and stability patches.[7][15] Musl follows a roughly time-based release schedule aimed at achieving long-term stability, with changelogs underscoring correctness, minimal feature additions, and thorough testing over rapid iteration.[16] This philosophy has enabled consistent milestones, from the production readiness of 1.0 to the security-focused evolutions in later series, without introducing breaking changes unless critical for compliance or safety.[7]| Version | Release Date | Key Milestones |
|---|---|---|
| 1.0.0 | March 20, 2014 | Initial stable release; production-ready with core standards support and static linking focus. |
| 1.1.0 | April 16, 2014 | Bootstrap enhancements; RELRO, VDSO, and IPv6 improvements. |
| 1.2.0 | February 20, 2020 | 64-bit time_t transition; Unicode 12.1.0 and Linux 5.x header support. |
| 1.2.5 | February 29, 2024 | statx, new architectures (loongarch64, riscv32); ongoing security patches into 2025. |
| 1.2.6 | Mid-2025 | Security fixes including CVE-2025-26519 (iconv out-of-bounds write). |
Design Philosophy
Core Principles
musl's design is fundamentally guided by the principle of simplicity, aiming for a minimalist codebase that minimizes bugs and facilitates auditing by avoiding unnecessary complexity. This approach unifies the C library, POSIX threads implementation, and dynamic linker into a single library, eliminating redundant code and ABI lock-in issues that arise from separate components. By streamlining the architecture, musl ensures that developers and auditors can more easily understand and verify the entire system, promoting reliability in resource-constrained environments.[17] A core tenet is strict standards conformance, adhering closely to the ISO C standard and POSIX specifications without incorporating GNU-specific extensions, which guarantees predictable and portable behavior across compliant systems. For instance, musl's implementation of thread cancellation follows POSIX requirements precisely, ensuring proper side effects and resource cleanup as defined by the Austin Group, even in scenarios where deviations could simplify development. This commitment extends to time handling, where internal use of 64-bit integers prevents overflows in POSIX time conversions, aligning with standard expectations for robustness.[17][18] musl prioritizes correctness over performance optimizations, favoring full specification compliance that may result in slower execution in edge cases but ensures safety and accuracy. In thread-local storage (TLS) management, for example, musl reserves all necessary storage upfront during allocation, allowing failures to be reported gracefully rather than leading to aborts or undefined behavior, which underscores a safety-first philosophy. This trade-off reflects the library's emphasis on verifiable correctness, reducing the risk of subtle errors that could compromise system integrity.[17][19] Portability is another foundational principle, with musl engineered for cross-architecture compatibility through a clean separation of Linux-specific elements, such as syscall interfaces, from standard C and POSIX components. The TLS subsystem, for instance, relies predominantly on portable POSIX C code with minimal machine-specific dependencies, enabling straightforward adaptation to diverse hardware without compromising core functionality. This design facilitates deployment on embedded systems and static binaries, where broad compatibility is essential.[17][20]Focus on Static Linking
musl is engineered with static linking as a foundational element, enabling the creation of self-contained binaries that incorporate all required library code directly into the executable, without reliance on a dynamic loader or external shared objects. This design inherently sidesteps dependencies on system dynamic linking infrastructure, such as the loader itself, which in turn mitigates security risks tied to dynamic loading mechanisms, including exploitation via environment variables like LD_PRELOAD that could inject malicious code.[11][21] The benefits of this static linking emphasis are multifaceted. It facilitates reproducible builds by embedding all components deterministically, free from variations introduced by shared library versions or system configurations on the build host. Distribution becomes simpler, as the resulting binary requires no additional library installations and can deploy across diverse Linux environments matching the target architecture. Furthermore, runtime overhead is minimized by eliminating dynamic symbol resolution and loading at startup, while binaries gain immunity to conflicts arising from mismatched or absent shared library versions on the host system.[2][11] At its core, musl's mechanisms for static linking prioritize modularity and minimalism to keep binaries lean. By avoiding heavy internal coupling among library components, it ensures that only the code and data pertinent to an application's needs are included, preventing the inadvertent incorporation of extraneous runtime elements like large global data structures. This approach also accommodates relocatable code generation, making it particularly apt for embedded systems where position-independent executables enhance flexibility in memory-constrained or firmware-like deployments.[2][11] A notable trade-off is the potential for increased binary sizes relative to dynamically linked counterparts, as all library functionality must be compiled in upfront. However, musl's compact footprint—yielding binaries as small as under 10 kB for threaded minimal programs and under 50 kB for practical applications—largely mitigates this, often resulting in more efficient overall resource usage compared to the bloat from dynamic linking dependencies.[2]Technical Features
Standards Compliance
musl provides comprehensive support for the ISO C standards, including full conformance to C99 (ISO/IEC 9899:1999) and C11 (ISO/IEC 9899:2011).[22][23] This includes implementation of core language features, standard library functions such asprintf for formatted output and malloc for dynamic memory allocation, as well as optional annexes like Annex F for IEC 60559 floating-point arithmetic.[22]
In terms of POSIX compliance, musl adheres to the POSIX.1-2008 (IEEE Std 1003.1-2008) base specifications, incorporating selected common extensions while maintaining a conservative approach to avoid non-standard additions.[1][24] It implements key POSIX interfaces, including wrappers for Linux system calls and utilities like getaddrinfo for address resolution, alongside full support for POSIX threads (pthreads) as the first post-NPTL implementation aimed at complete conformance and robustness. This enables portability for applications relying on standard Unix-like behaviors without proprietary extensions.
However, musl intentionally omits certain deprecated or non-standard features to prioritize simplicity and correctness, such as BSD-specific socket extensions beyond POSIX requirements.[21] For instance, dlclose is implemented as a no-op, meaning dynamically loaded libraries remain in memory for the process lifetime, which aligns with POSIX allowances but differs from more aggressive unloading in other implementations.[21]
musl lacks formal certification from standards bodies, but its development emphasizes rigorous testing against conformance suites, including the libc-test framework, which verifies correctness and quality across standard library implementations.[25][26]
Security and Performance Optimizations
musl's security model emphasizes a compact codebase to minimize the attack surface, with a static library size of approximately 426 kB. This reduced size limits potential vulnerabilities compared to larger implementations like glibc, which can exceed several megabytes. By prioritizing simplicity and correctness in its design, musl avoids complex features that could introduce bugs or exploitable weaknesses, relying on rigorous code review and adherence to standards rather than layered mitigations. Unlike glibc, which includes default stack smashing protection (SSP) for user applications to guard against buffer overflows, musl does not enable such runtime checks by default, instead focusing on preventing overflows through precise implementations that terminate processes rapidly upon detection of issues like stack protector failures or double-frees in internal code paths.[27][2][28][29] In terms of performance, musl is optimized for static linking, resulting in a low memory footprint where global data remains under 8 KB and minimal static-linked binaries can be as small as 10 KB, even with threading support. This efficiency stems from avoiding unnecessary dynamic allocations in core library paths, ensuring predictable behavior and reduced overhead in resource-constrained environments. For instance, musl implements string functions likeisalnum using straightforward logical checks (e.g., isalpha(c) || isdigit(c)) rather than precomputed lookup tables, prioritizing correctness and simplicity over marginal speed gains from complexity. Such choices contribute to faster startup times and lower resource usage on embedded hardware, where the library's lean design outperforms bulkier alternatives despite occasional trade-offs in raw computational benchmarks.[2][2][30]
Further optimizations include streamlined handling of networking protocols, where musl performs parallel DNS queries across up to three nameservers, accepting the first valid response to enhance reliability without introducing bloat from sequential fallbacks or extensive IDN support. IPv6 integration uses unified sockets for both IPv4 and IPv6 traffic, avoiding redundant code paths and promoting efficiency in mixed environments. These approaches reflect musl's philosophy of favoring simple, robust algorithms that yield reasonable performance across scenarios, though simplicity can lead to slower execution in highly optimized, multi-threaded workloads on powerful hardware—contrasted by superior responsiveness on limited-resource systems due to the minimized footprint.[21][21][2]
Implementation Details
Supported Architectures
musl libc provides support for a variety of hardware architectures and application binary interfaces (ABIs) tailored to Linux systems, emphasizing portability and minimal dependencies to facilitate use in embedded and resource-constrained environments.[31] The primary supported architectures include x86 (both 32-bit i386 with SysV ABI and 64-bit x86_64 with SysV ABI), ARM (EABI for armv4t and later, including soft-float variants requiring GCC 4.2.4 or later and hard-float variants requiring GCC 4.5.4 or later), AArch64, MIPS (o32, n32, and n64 ABIs for MIPS1+ or MIPS2+, with support for both big-endian and little-endian variants like mips and mipsel), PowerPC (32-bit and 64-bit, with both little-endian and big-endian support using GCC with secure PLT enabled), RISC-V (64-bit since version 1.1.23 with soft-float, and full 32-bit support added in 1.2.5), LoongArch64 (since 1.2.5), MicroBlaze (requiring Xilinx toolchain and Linux kernel 3.13+), OpenRISC 1000, s390x, and m68k.[31][7] These cover standard Linux ABIs, ensuring compatibility with the POSIX interface on kernels version 2.6.39 or later for full conformance, though simpler applications may run on older kernels like 2.4.[31] Experimental or partial support exists for architectures such as x32 (requiring GCC 4.7+ and Linux 3.4+, with known kernel issues) and SuperH (sh, including subvariants like sheb and sh-nofpu, often needing kernel patches).[31] RISC-V support, initially merged for 64-bit in 1.1.23, achieved fuller coverage with 32-bit in 1.2.5, demonstrating musl's ongoing expansion for emerging platforms.[7] musl's clean, modular design—featuring a C-based common runtime framework for startup code—enables relatively quick porting of new architectures by the community, as seen in contributions for OpenRISC and PowerPC variants.[32] Developers can leverage tools like libc-test for validation during ports, fostering community-driven additions for niche platforms.[32] Limitations include exclusive focus on Linux kernels, with no support for Windows or other non-Linux environments, and a primary emphasis on little-endian byte order, though big-endian is accommodated where architecturally feasible, such as in PowerPC and MIPS implementations.[31]Key Internal Components
musl's memory allocator, known as malloc, is a customized variant of Doug Lea's dlmalloc, adapted with fine-grained locking to enhance multi-threaded performance while maintaining simplicity suitable for static linking.[33] This design avoids the complexity of glibc's ptmalloc by using per-bin locks rather than a single global lock, reducing contention in concurrent environments and ensuring compatibility with fully static binaries where dynamic replacement is not possible.[33] In version 1.2.0 and later, musl introduced mallocng, a next-generation allocator that further improves robustness and efficiency, addressing limitations in the original implementation such as unbounded heap expansion races.[7] The I/O subsystem in musl features streamlined handling of FILE* streams through direct integration with Linux system calls like readv and writev, promoting efficient buffering without relying on complex heuristics.[21] For networking, socket wrappers are implemented to ensure correct propagation of errors from underlying syscalls, adhering strictly to POSIX semantics for functions like connect and accept, which helps in predictable behavior across threaded applications.[21] This approach minimizes overhead and supports static linking by avoiding dependencies on external buffering libraries. musl's dynamic linker, ld.so, is a minimal implementation integrated directly into libc.so to reduce startup overhead and enable atomic upgrades of the entire library via a single rename operation. It performs permanent loading of shared libraries for the process lifetime, treating dlclose as a no-op to simplify state management and avoid potential issues with unloading, which aligns with POSIX allowance but prioritizes reliability over dynamic reloading.[21] Threading support in musl provides basic POSIX pthread functionality, leveraging Linux futexes for synchronization primitives like mutexes and condition variables to enable efficient user-space operations without kernel involvement in uncontended cases.[34] This implementation focuses on core features such as thread creation, joining, and cancellation, using atomic operations and futex syscalls for locking, while omitting advanced scheduling policies to keep the codebase lightweight and suitable for embedded use.Comparisons
With glibc
musl and glibc differ significantly in size and complexity, with musl designed to be lightweight and minimalistic. As of 2015, the complete shared object set for musl totaled approximately 527 KB, in contrast to glibc's roughly 7.9 MB including additional iconv modules (~5 MB).[35] More recent assessments as of 2025 indicate musl's core library remains under 1 MB, while glibc occupies tens of megabytes on disk, especially with locales and development files.[36] This smaller footprint arises from musl's focus on essential functionality without the extensive features and optimizations accumulated in glibc over decades.[37] Regarding API behaviors, musl adheres more strictly to standards, leading to simpler and safer implementations; for instance, in functions likestrtoll, musl consistently sets errno on underflow conditions where glibc may not, enhancing predictability for developers relying on error reporting.[38][39]
In dynamic linking, glibc employs a flexible loader (ld.so) that supports unloading libraries via dlclose and handles complex dependency resolution, but this flexibility has historically introduced vulnerabilities, such as those exploited in loader attacks.[21] Conversely, musl's dynamic linker loads libraries permanently for the process lifetime, treating dlclose as a no-op to simplify the model and reduce potential security risks from dynamic unloading.[21] This approach aligns with musl's emphasis on reliability in resource-constrained environments but limits advanced dynamic loading scenarios supported by glibc.
Performance profiles between musl and glibc vary by workload. glibc often outperforms musl in compute-intensive tasks due to specialized optimizations, such as in regular expression matching where glibc's vectorized implementations yield higher throughput.[36] However, musl excels in static linking and embedded scenarios, where its smaller code size reduces memory usage and startup time, making it preferable for containers and low-resource systems.[40] As of 2024, optimized musl variants (e.g., in Alpaquita Linux) match or exceed glibc performance in some ARM workloads, though default musl allocators can cause up to 7x slowdowns in certain multithreaded benchmarks compared to glibc.[41][42] Benchmarks on multithreaded applications sometimes show glibc's advantages in allocation efficiency, but musl's simplicity can lead to faster execution in minimalistic, single-threaded programs.[36]
Compatibility challenges stem from glibc's inclusion of non-standard extensions and differing behaviors not present in musl, which prioritizes POSIX and C standard compliance. For example, glibc supports proprietary extensions like nscd caching for name resolution, absent in musl, requiring applications to adapt or use alternatives.[21] Behavioral differences include getaddrinfo handling of IPv6; when called with AF_UNSPEC, glibc may return IPv4-mapped IPv6 addresses for hosts without native IPv6 support, whereas musl strictly adheres to separate family resolution and avoids such mappings to prevent unexpected dual-stack behavior.[43] These variances can cause portability issues for software assuming glibc-specific quirks, though musl's predictability aids in cross-library verification.[44]