Category: Uncategorized

More on Intel FSP

~ hucktech ~ Leave a comment

First, Vincent replied to my last FSP post with an URL to another FSP-related spec, the Boot Setting File (BSF) spec, see the comments here:

Intel FSP 2.0

Click to access BSF_1_0.pdf

Second, Vincent has two posts of his own on FSP, I may’ve blogged about one, but I believe the other one is new, there’s a lot of new FSP links to start learning…:

http://vzimmer.blogspot.com/2016/04/open-source-platforms-fsp-consumers-fsp.html

https://firmware.intel.com/blog/open-source-platforms-edkii-using-intel-fsp

 

update on Atom’s demise: Minnow’s swim on

~ hucktech ~ Leave a comment

It appears that the Minnows may be spared from the recent news of Atom’s demise, see the below comments from Intel on the subject:

http://lists.elinux.org/pipermail/elinux-minnowboard/Week-of-Mon-20160502/002239.html

 

https://plus.google.com/+MinnowboardOrg/posts/CBGiLXRexxt

 

Intel FSP 2.0

~ hucktech ~ 1 Comment

Jiewen Yao of Intel submitted a 19-part patch to the UEFI Forum’s EDK2 project today, adding Intel FSP 2.0 support.

(The comments for the patch are also the first time I’ve seen a pointer to the 2.0 FSP spec. Strangely, at the moment Intel.com is down for me, though the rest of the intarwebs appears to be up, so I cannot verify the FSP PDF URL…)

This series of patch is to support FSP2.0 specification at
https://firmware.intel.com/sites/default/files/FSP_EAS_v2.0_Draft%20External.pdf

Some major updates include:
1) One FSP binary is separated to multiple components:
FSP-T, FSP-M, FSP-S, and optional FSP-O.
Each component has its own configuration data region.
2) All FSP-APIs use same UPD format – FSP_UPD_HEADER.
3) Add EnumInitPhaseEndOfFirmware notifyphase.
4) FSP1.1/FSP1.0 compatibility is NOT maintained.

The new Intel platform will follow FSP2.0.
The old platform can either use an old EDK branch, or move FSP1.1 support to platform directory.

We also add rename Fsp* to FspWrapper* in IntelFspWrapperPkg, to indicate that it is for FspWrapper only.

  IntelFspPkg: Update FSP header file to follow FSP2.0 spec.
  IntelFspPkg: Update FSP private header file used by FSP2.0 implementation.
  IntelFspPkg-FspCommonLib: Update FSP common lib for FSP2.0.
  IntelFspPkg/FspPlatformLib: Update FSP platform lib for FSP2.0.
  IntelFspPkg/FspSecPlatformLib: Update FSP SecPlatform lib for FSP2.0.
  IntelFspPkg/FspSecCore: Update FSP SecCore for FSP2.0.
  IntelFspPkg/FspNotifyPhase: Separate FSP NotifyPhase from DxeIpl to new module.
  IntelFspPkg: Update DEC/DSC for FSP2.0.
  IntelFspPkg/Tool: Update FSP tool for FSP2.0.
  IntelFspWrapperPkg/Ppi: Update FspInitDone to FspSiliconInitDone.
  IntelFspWrapperPkg/FspWrapperApiLib: Update FspApiLib to FspWrapperApiLib.
  IntelFspWrapperPkg/FspWrapperApiTestLib: Add ApiTestLib as hook.
  IntelFspWrapperPkg/FspWrapperHobProcessLib: Update FspHobProcessLib to FspWrapperHobProcessLib.
  IntelFspWrapperPkg/FspWrapperPlatformLib: Update FspPlatformInfoLib to FspWrapperPlatformLib.
  IntelFspWrapperPkg/FspWrapperPlatformSecLib: Align PlatformSecLib defined in UefiCpuPkg.
  IntelFspWrapperPkg/FspWrapperSecCore: Remove FspWrapperSecCore.
  IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.
  IntelFspWrapperPkg/FspWrapperNotifyDxe: Update FspNotifyDxe to FspWrapperNotifyDxe.
  IntelFspWrapperPkg: Update DEC/DSC for FSP2.0.

For more info, see the full patch sent to the EDK2-devel list:
https://lists.01.org/mailman/listinfo/edk2-devel

coreboot 4.4 released!

~ hucktech ~ Leave a comment

coreboot version 4.4 has been released, which includes 850 commits by 90 authors added 59000 lines to the codebase since their last quarterly release. This release includes OpenPOWER support and experimental U-Boot payload support. It also has an Intel ME tool which is new (at least to me). There are many other changes, excerpting their announcement:

Significant changes:
* Build system (30 commits) – Add postcar stage, ‘timeless’ builds, extend site-local, test toolchain by version string, update dependencies, catch ACPI errors, l add additional macros.
* Toolchain updates (40+ patches) – Update IASL to v20160318 , LLVM to v3.7.1, add GNU make, add nds32le GCC compiler
* Lint tools (30 patches) – Update existing lint utilities, add lint tests for executable bit, make sure site-local isn’t committed, add test to break all lint tests.
* Payloads (60 commits) – Fixes for libpayload, coreinfo and nvramcui, add new payloads, see below.
* Maintainers file – (8 patches) – continue adding maintainers for various areas.
* Documentation for adding Intel FSP-based platforms (20 commits)

New architectures:
* power8
* qemu-power8

New payloads:
* depthcharge: For ChromeOS verified boot
* iPXE: For network booting
* Memtest86+: Updated with fixes for correctly testing coreboot with payloads
* U-Boot (Experimental): Alternate payload for booting an OS

New/updated mainboards:
* asus/kcma-d8
* emulation/qemu-power8
* google/auron_paine
* google/gru
* intel/amenia
* intel/apollolake_rvp
* intel/camelbackmountain_fsp
* intel/galileo
* lenovo/t420
* asus/kgpe-d16
* google/oak
* google/chell
* intel/kunimitsu

New/updated socs:
* intel/apollolake
* intel/fsp_broadwell_de
* intel/quark
* marvell/armada38x
* rockchip/rk3399
* cpuamd/mct_ddr3
* drivers/intel/fsp2_0
* northbridge/intel/sandybridge/raminit
* soc/intel/apollolake
* soc/intel/fsp_baytrail
* soc/intel/skylake
* soc/mediatek/mt8173

New vendorcode directories:
* siemens

New/updated submodules:
* chromeec
* 3rdparty/arm-trusted-firmware (329 commits)
* 3rdparty/vboot (28 commits)
* util/nvidia/cbootimage (13 commits)

New/updated Utilities:
* archive – Concatenates files into a single blob with an indexed header
* chromeos – Download and extract blobs from a ChromeOS image
* futility – vboot Firmware utility
* intelmetool – Shows information about the Intel ME on a platform.
* marvell/doimage_mv – No usage notes
* post – Simple utility to test post cards

Full announcement:

Announcing coreboot 4.4


https://www.coreboot.org/releases/

Intel to kill off Atom line (?)

~ hucktech ~ Leave a comment

Intel Atom line is apparently in danger, after recent corporate reorg.

http://www.intel.com/content/www/us/en/processors/atom/atom-processor.html
http://www.xda-developers.com/intel-cutting-significant-part-possibly-entire-atom-lineup/
http://www.pcworld.com/article/3063672/windows/the-death-of-intels-atom-casts-a-dark-shadow-over-the-rumored-surface-phone.html
http://www.pcworld.com/article/3063508/components/intel-is-on-the-verge-of-exiting-the-smartphone-and-tablet-markets-after-cutting-atom-chips.html

Workaround: if you put a liliputing.com-based URL in a WordPress post, any subsequent text after that URL will be omitted, the Liliputing URL must be the last text in the WordPress post. 😦
http://liliputing.com/2016/04/reports-intel-is-killing-off-low-power-atom-chips.html

 

RAP

~ hucktech ~ Leave a comment

 

“RAP is here. Public demo in 4.5 test patch and commercially available today! Today’s release of grsecurity® for the Linux 4.5 kernel marks an important milestone in the project’s history. It is the first kernel to contain RAP, a defense mechanism against code reuse attacks. RAP was announced to the world at the H2HC conference in October 2015 and represents the best available solution of its type. RAP is the result of our multi-years research and development in Control Flow Integrity (CFI) technologies by PaX. It ground-breakingly scales to C and C++ code bases of arbitrary sizes and provides best-effort protection against code reuse attacks with minimal performance impact. The public version of RAP available in the grsecurity test kernels from now on demonstrates a subset of the features in the full version, available today for commercial licensing from Open Source Security, Inc. The demo version will evolve over time, but is currently tailored for x64 kernel use only and does not support C++, link-time optimization, compile time static analysis, and probabilistic return address protection. In addition, the demo’s GPLv2 license excludes userland applications due to the GCC library runtime exception for GCC plugins.” […]

https://grsecurity.net/rap_announce.php
https://grsecurity.net/rap_faq.php
https://grsecurity.net/features.php

Click to access PaXTeam-H2HC15-RAP-RIP-ROP.pdf

ARM Technical Learning Resources

~ hucktech ~ Leave a comment

Tom Stevens of ARM posted a blog with a new list of links for developers new to ARM. About 40 links, mostly on ARM assembly and C, Cortex-M, NEON, ARMv8/AArch64. Here’s a list of the initial 10 or so links’s titles:

Getting Started with ARM Microcontroller and Assembly Programming
How to Load Constants in Assembly for ARM Architecture
Branch and Call Sequences Explained
Building Customized Debug and Trace Solutions for Multicore SoCs
Caches and Self-Modifying Code
Code Size: A Comprehensive Comparison of MicroMIPS32 and Thumb Code Size Using Many Megabytes of Customer Code
How to Call a Function from ARM Assembler
Designing in ARM: Part One- Switching Microcontrollers
Getting Started with ARM Assembly and C Programming
Detecting Overflow from MUL

Full article:
https://community.arm.com/groups/processors/blog/2015/03/03/important-arm-technical-learning-resources

If this were done outside ARM.com, it’d probably github-hosted and called ‘awesome-arm-development.md’. (BTW, I’m slowly working on an ‘awesome firmware’ link collection, if someone doesn’t do one first…)

EopMon: EoP detector for Intel VT-x

~ hucktech ~ Leave a comment

Satoshi Tanda has created EopMon, an elevation-of-privilege detector for Windows 7/8.1/10 on Intel x86 and x64 systems which support Intel VT-x and EBT.

EopMon is based his earlier project, HyperPlatform, which is also worth checking out, along with MemoryMon and GuardMon.

EopMon is a hypervisor-based elevation of privilege (EoP) detector. It can spots a process with a stolen system token and terminate it by utilizing hypervisor’s ability to monitor process context-swiching. […] While EopMon is tested against multiple EoP exploits carried out by in the wild malware, it is rather meant to be an educational tool to demonstrate a potential use case of a hypervisor for security research and not aimed for comprehensive exploit prevention. […] EopMon is meant to be an educational tool and not robust, production quality software which is able to handle various edge cases. […] For this reason, researchers are encouraged to use this project only as a reference to examine and develop ideas of using a hypervisor.

https://github.com/tandasat/EopMon
https://github.com/tandasat/HyperPlatform
https://github.com/tandasat/MemoryMon
https://github.com/tandasat/GuardMon

Reversing Huawei router part 2: U-Boot’s CLI

~ hucktech ~ Leave a comment

Juan Carlos Jiménez has written the 2nd part of his series on reversing a Huawei router! The first part was excellent, this one is just as good.

Practical Reverse Engineering Part 2 – Scouting the Firmware

In part 1 we found a debug UART port that gave us access to a linux shell. At this point we’ve got the same access to the router that a developer would use to debug issues, control the system, etc. This first overview of the system is easy to access, doesn’t require expensive tools and will often yield very interesting results. If you want to do some hardware hacking but don’t have the time to get your hands too dirty, this is often the point where you stop digging into the hardware and start working on the higher level interfaces: network vulnerabilities, ISP configuration protocols, etc. […]

Part 2:
http://jcjc-dev.com/2016/04/29/reversing-huawei-router-2-scouting-firmware/

Part 1:

Huawei HG533 reversing, part I


http://jcjc-dev.com/2016/04/08/reversing-huawei-router-1-find-uart/

Intel ATR site updates it’s research on web site

~ hucktech ~ Leave a comment

Intel Advanced Threat Research (ATR) is home of the CHIPSEC team. They just updated their web site with more presentation archives.

http://www.intelsecurity.com/advanced-threat-research/index.html

BIOS mod lab at upcoming SecuringHardware.com training

~ hucktech ~ Leave a comment

For those who need Evil Maid skills take note: Joe Fitzpatrick has added a BIOS mod lab to his Black Hat training on x86 physical attacks.

Applied Physical Attacks on x86 Systems
Joe FitzPatrick, SecuringHardware.com
July 30-August 2

This course introduces and explores attacks on several different relatively accessible interfaces on x86 systems. Attendees will get hands-on experience implementing and deploying a number of low-cost hardware devices to enable access, privilege, and deception which is in some cases imperceptible from software. The course has several modules: USB, SPI/BIOS, I2C/SMBus, PCIe, and JTAG. Each begins with an architectural overview of an interface, and follows with a series of labs for hands-on practice understanding, observing, interacting with, and exploiting the interface, finishing with either potentially exploitable crashes or directly to root shells.

https://www.blackhat.com/us-16/training/applied-physical-attacks-on-x86-systems.html

new CHIPSEC changes

~ hucktech ~ Leave a comment

As I understand things, Intel has a private source tree for CHIPSEC, and makes snapshots of [a subset of] this private tree to their public github.com-hosted source tree. As a result, CHIPSEC usually doesn’t release incrementally, updates usually come in big batches. So it is a surprise to see some recent incremental changes to the CHIPSEC public code tree. Here are some commits between mid-March and today:

Merge pull request #26 from tweksteen/cmos_test_reviewed
Merge pull request #25 from tweksteen/spi_test_reviewed
Merge pull request #27 from tweksteen/x1_carbon_test_reviewed
Merge pull request #23 from tweksteen/fix_i386_linux_driver
Remove unused setUp and tearDown
Add hardware test for X1 Carbon
Add test for CMOS dump
Add test for SPI info
Merge pull request #24 from tweksteen/raise_oshelper
Merge pull request #22 from tweksteen/sort_acpi_tables
Change sys.exit to re-raise
Sort ACPI tables by name
Fix Linux driver build on i386
Merged changes from #17 pull request
removed win specific cleanup script
Merge pull request #21 from chipsec/dev
Merge pull request #11 from tweksteen/setup
Merge pull request #14 from tweksteen/uefi_clean_up
Fix ACPI RSDP resolution based on EBDA
Add tests for ACPI RSDP, RSDT and XSDT.
Add basic tests
Fix Linux helper close
Do not force kernel module loading on Linux
Use metaclass to autoload helpers

https://github.com/chipsec/chipsec
https://github.com/chipsec/chipsec/commits/master

many EFI changes in Linux 4.7 queue

~ hucktech ~ Leave a comment

Matt Fleming posted a 40-part (!) patch, with the queue of UEFI changes for Linux 4.7 kernel. Edited version of Matt’s part0 comments follow:

Folks, here’s the queue of EFI material for v4.7. This is probably the biggest EFI pull ever sent, and there quite a few different topics covered. On the plus side the majority of new features (EFI Memory Attribute tables, EFI capsules, GOP framebuffer) are basically architecture independent, and some of the existing architecture-specific code has been generalised and moved to drivers/firmware/efi.

 * Drop the unused EFI_SYSTEM_TABLES efi.flags bit and ensure the ARM/arm64 EFI System Table mapping is read-only
 * Add a comment to explain that one of the code paths in the x86/pat code is only executed for EFI boot
 * Improve Secure Boot status checks on arm64 and handle unexpected errors
 * Remove the global EFI memory map variable ‘memmap’ as the same information is already available in efi::memmap
 * EFI Memory Attribute table support for ARM/arm64
 * EFI GOP framebuffer support for ARM/arm64
 * EFI Bootloader Control driver for storing reboot(2) data in EFI variables for consumption by bootloaders
 * Core EFI capsule support
 * EFI capsule char driver
 * EFI memory map code unification for ARM and arm64
 * Add generic EFI support for detecting when firmware corrupts cpu status register bits (like IRQ flags) when performing EFI runtime service calls

Ard Biesheuvel (19):
      efi: Get rid of EFI_SYSTEM_TABLES status bit
      efi/arm*: Drop writable mapping of the UEFI System table
      efi: Check EFI_MEMORY_DESCRIPTOR version explicitly
      efi/arm*: Use memremap() to create the persistent memmap mapping
      ARM: efi: Apply strict permissons for UEFI Runtime Services regions
      arm64: efi: Apply strict permissons for UEFI Runtime Services regions
      efi: Add support for the EFI_MEMORY_ATTRIBUTES_TABLE config table
      efi: Implement generic support for the Memory Attributes table
      efi/arm*: Take the Memory Attributes table into account
      x86/efi: Prepare GOP handling code for reuse as generic code
      efi/libstub: Move Graphics Output Protocol handling to generic code
      x86/efi: efifb: Move DMI based quirks handling out of generic code
      efifb: Use builtin_platform_driver and drop unused includes
      arm64/efi: libstub: Make screen_info accessible to the UEFI stub
      efi/arm: libstub: Make screen_info accessible to the UEFI stub
      efi/arm*: libstub: Wire up GOP protocol to struct screen_info
      efi/arm*: Wire up struct screen_info to efi-framebuffer platform device
      efifb: Enable the efi-framebuffer platform driver for ARM and arm64
      efi/arm-init: Reserve rather than unmap the memory map for ARM as well

Compostella, Jeremy (1):
      efibc: EFI Bootloader Control

Kweh, Hock Leong (1):
      efi: A misc char interface to update EFI firmware

Linn Crosetto (2):
      efi/arm64: Report unexpected errors when determining Secure Boot status
      efi/arm64: Check SetupMode when determining Secure Boot status

Mark Rutland (10):
      efi/runtime-wrappers: Add {__,}efi_call_virt templates
      arm64/efi: Move to generic {__,}efi_call_virt
      arm/efi: Move to generic {__,}efi_call_virt
      x86/efi: Move to generic {__,}efi_call_virt
      efi/runtime-wrappers: Remove redundant ifdefs
      efi/runtime-wrappers: Detect firmware irq flag corruption
      arm64/efi: Enable runtime call flag checking
      arm/efi: Enable runtime call flag checking
      x86/efi: Enable runtime call flag checking
      efi/runtime-wrappers: Remove ARCH_EFI_IRQ_FLAGS_MASK ifdef

Matt Fleming (7):
      x86/mm/pat: Document the (currently) EFI-only code path
      efi: Iterate over efi.memmap in for_each_efi_memory_desc
      efi: Remove global ‘memmap’
      x86/efi: Remove the always true EFI_DEBUG symbol
      efi: Move efi_status_to_err() to drivers/firmware/efi/
      efi: Capsule update support
      x86/efi: Force EFI reboot to process pending capsules

For the full patch, see the Linux-EFI mailing list archives:
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-next
http://vger.kernel.org/majordomo-info.html

U-Boot Verified Boot to get security improvements

~ hucktech ~ Leave a comment

Teddy Reed is proposing a change to U-Boot to support multiple levels of signing keys. Currently this is still at discussion phase, here’s Teddy’s initial post.

I’m looking to support “multiple levels” of keys within u-boot’s verified boot. I need something similar to UEFI’s key enrollment key (KEK) and db/dbx model such that I can support on-line signing of new kernels/rootfs/configurations. To make this work we need a KEK that is not online (kept in a safe), that can be used to sign expirations (revocations) of on-line signing keys in the case of compromise or private key reveals. I know Chrome’s Coreboot verified boot model supports this, wondering if there’s any staged / WIP for u-boot? Off the top of my head I’d imagine this requires extending the FIT to include sets of public keys and a blacklist of keys and expired or bad kernel/rootfs/etc hashes. Then either extending the boot code to inspect multiple FITs or extending mkimage to combine multiple sources to amalgamate a FIT containing the PK-signed set of keys + hashes and the on-line key-signed kernels/rootfs/configurations.

P.S. This may be strongly linked to the need for a TPM to prevent rollbacks. But as far as I can tell, the two features are distinct and a TPM is not completely required for a multi-level key approach to signing FITs.

Full post/thread:
http://lists.denx.de/mailman/listinfo/u-boot

AMD’s Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV)

~ hucktech ~ Leave a comment

Linux is about to get more secure on some AMD systems, it seems… Tom Lendacky of AMD submitted an 18-part patch to many of the Linux dev lists, to add support for AMD’s new Secure Memory Encryption (SME) feature, and to prepare for an upcoming Secure Encrypted Virtualization (SEV) patch.

SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is marked encrypted will be automatically decrypted when read from DRAM and will be automatically encrypted when written to DRAM. Details on SME can found in the links below. The SME feature is identified through a CPUID function and enabled through the SYSCFG MSR. Once enabled, page table entries will determine how the memory is accessed. If a page table entry has the memory encryption mask set, then that memory will be accessed as encrypted memory. The memory encryption mask (as well as other related information) is determined from settings returned through the same CPUID function that identifies the presence of the feature. The approach that this patch series takes is to encrypt everything possible starting early in the boot where the kernel is encrypted. Using the page table macros the encryption mask can be incorporated into all page table entries and page allocations. By updating the protection map, userspace allocations are also marked encrypted. Certain data must be accounted for as having been placed in memory before SME was enabled (EFI, initrd, etc.) and accessed accordingly.

This patch series is a pre-cursor to another AMD processor feature called Secure Encrypted Virtualization (SEV). The support for SEV will build upon the SME support and will be submitted later.

AMD Memory Encryption whitepaper:

Click to access AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer’s Manual:

Click to access 24593.pdf

SME is section 7.10
SEV is section 15.34

https://lkml.org/lkml/2016/4/26/1109
https://lkml.org/lkml/2016/4/26/1114
http://www.amd.com/en-us/innovations/software-technologies/security
http://www.amd.com/en-us/solutions/pro/security-manageability

For the patch, see the Linux-kernel or Linux-EFI (or other) lists:
http://vger.kernel.org/majordomo-info.html

Configurable or Secure, pick ONE

~ hucktech ~ Leave a comment

<soapbox>

Recently I posted a comment about a vendor who is starting to sign their firmware, which is good for security. Paul points out in the comments section of that post the other side of that situation, configurability:

Schneider to sign PLC firmware

Today, Brian of Intel’s UEFI team points out a story about new Apple laptops including tamper-resistant screws:

http://gizmodo.com/apple-will-know-if-youve-tampered-with-its-new-macbooks-1773045604

As Paul mentions in his comments, Google makes a ChromeBook targetting developers with a Developer Mode, a screw to turn to let you override firmware/OS security.
https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/chromebook-pixel-2015#TOC-Developer-Mode

I hope PC/smartphone/tablet/router/IoT vendors consider the situation of the consumer in a use case when the company abandons the product and no longer offers firmware/software updates, and the only person to refurbish the flaws in the unsupported firmware is the user, and they will need the ability to bypass the security features that only permit the company’s firmware from being loaded, or else the device will be a useless brick. The model that Google ChromeBooks have: a Developer Mode, may be the best option. If you are unsure about this, do an experiment with your next device, add a similar Developer Mode it to some models, and charge a bit more for hobbyists, and see if there is a market. Abandoned products aside, advanced users can build better firmware/software than you can, look at how the camera hackers have added features the vendor never thought of? This is another way you can grow the ecosystem and popularity of your device, and generate more sales/profit. Don’t seal all devices in the name of security, please.

</soapbox>

Routersploit

~ hucktech ~ Leave a comment

Routesploit is like Metasploit, written in Python, not Ruby, taretting embedded devices.

It consists of various modules that aids penetration testing operations:
* exploits – modules that take advantage of identified vulnerabilities
* creds – modules designed to test credentials against network services
* scanners – modules that check if target is vulnerable to any exploit

https://github.com/reverse-shell/routersploit

RouterSploit – Router Exploitation Framework
byu/lucyoa innetsec

https://asciinema.org/a/8u75xcjuacnbpwz9feaixde9e?autoplay=1

LibC library musl ported to UEFI

~ hucktech ~ Leave a comment

Michael Zimmerman, one of the main developers behind EFIDroid, also has another interesting UEFI side project: uefi-musl-toolchain, a port of the LibC library musl to UEFI!

Quoting Wikipedia, musl is “a C standard library intended for operating systems based on the Linux kernel, released under the MIT License. It was developed by Rich Felker with the goal to write a clean, efficient and standards-conformant libc implementation. It is designed from scratch to allow efficient static linking and to have realtime-quality robustness by avoiding races, internal failures on resource exhaustion and various other bad worst-case behaviours present in existing implementations. 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.

On his musl port to UEFI, Michael says:

I ported the libc alternative musl to UEFI by replacing the syscalls with simple function calls to library and wrote a GCC wrapper. The system call table is still incomplete but this way I can compile any (single-threaded) application for UEFI. This currently works on ARM only, but just because this is the platform I am interested in, not because it wouldn’t be possible.

This is fresh code, the project is only 2 days old. 🙂

https://github.com/M1cha/uefi-musl-toolchain

Example of busybox on UEFI compiled using musl: http://pastebin.com/MRXdBjyN

https://www.musl-libc.org/