A love story

BIO

  • Head of 9elements Cyber Security
  • Founder of the Open Source Firmware Conference
  • coreboot & LinuxBoot project member
  • Das-Labor Hackerspace member
  • IT-Security background 10+ years
  • Firmware Developer since 5+ years 

  Twitter: _zaolin_ , 9eSec

Motivation

  • A firmware talk on a rookie level
    • We want new firmware developers!!
  • Basic Input Output System is dead since 2000
  • A short story about closed source firmware and a man with his CPU cluster 20 years ago at Los Alamos National Laboratory
  • "Press F2 to continue..."

Let's talk about Hardware

Facebook Open Cellular

github.com/Telecominfraproject/OpenCellular

EC firmware

Host processor

firmware

TPM firmware

Power supply

firmware

OEM/ODM

  • Original Design/Equipment Manufacturer
  • Lenovo, Dell, HP, Google, OCP (OEM)
    • They are contracting companies like Wistron, and Quanta (ODM)
  • They are the customers of the System On Chip vendors 
    • Intel, AMD, Qualcomm, Cavium, IBM, SiFive
  • Most OEMs contract Independent Bios Vendors to outsource their firmware development

Host processor firmware / BIOS

PCB flash memory

  • NOR flash
    • SPI Bus
    • High speed
    • High-cost solution
    • Easy platform integration

 

  • EMMC
    • SD/MMC Bus
    • Slow speed
    • Low-cost solution
    • Complex controller initialization

SoC flash memory

  • Low storage capacity
  • Fully integrated into SoC
  • Extreme low-cost solution

NOR flash memory capacity

1980

Today

64KB

512KB

2MB

8MB

32MB

512MB

IBV

  • So-called Independent BIOS Vendors
    • AMI, Phoenix Technologies, Insyde and much more...
    • Most of them selling closed source firmware as a product
    • Some doing Open Source work for U-Boot, coreboot and TianoCore
    • Often they are needed because of the complex platform initialization
    • Closed source firmware standards
      • Royalty fees
      • SDK costs

IBV example

How does Firmware work?

From flash memory to the OS

Every firmware is different but...

  1. Execution of initial code of firmware at reset vector
  2. Initializes or utilizes SRAM/CAR
  3. Set up system RAM and CPU caching
  4. Runs device drivers for platform initialization
  5. Set up operating system requirements
  6. Run bootloader in firmware
  7. Run bootloader before OS
  8. Launch the OS

Flash memory descriptor

  • Some SoC vendors decide to have their own partition table inside the flash memory
  • e.g. Intel Firmware Descriptor
  • Used as additional config source for Intel ME!
  • Contents of the IFD:
    • Flash Descriptor
    • GBE
    • Intel ME
    • BIOS
    • Platform Data

FDT

GBE

ME

BIOS

ROMCC

Legacy

  • Open Source ROM compiler which compiles the initial code block on x86 legacy platforms
  • Created as part of the coreboot project by Eric Biederman
  • One file and 21584 lines of code
  • Compiler uses register as memory
  • Needed because no stack/heap memory is available
  • Too many nested code blocks lead to register overflow

SRAM / CAR

Modern

  • Modern platforms provide early SRAM or Cache As RAM setup
  • Gives us few megabytes of usable memory for the firmware
  • ROMCC isn't needed anymore because we can use stack/heap with a normal compiler like GCC
  • CAR is present on x86 platforms mostly

Reset Vector

  1. SoC loads the first code of the firmware from a platform-dependent CPU address space by
    • MMAP flash memory, mostly on x86
    • Copying contents (initial code) of the flash memory into SRAM
      • Maps portion of SRAM into CPU address space
  2. CPU jumps to reset vector address and executes initial bootblock code

Initial Bootblock

  • Initial code executed from reset vector (IBB)
  • Some are written in pure Assembly but later in C code
  • Initializes or utilizes SRAM/CAR
  • SPI and firmware filesystem driver
  • Sets up platform features like
    • Board Reset
    • Early serial console
    • Early microcode updates

ROM stage

  • RAM training
    • Firmware uses static values or calculates training data
    • Soldered memory
      • Read memory info (SPD) from firmware
    • Normal memory
      • Read memory info (SPD) from I2C EEPROM
    • Often training data is cached in firmware for faster boot time

ROM stage

  • MMU & Page table setup for more than >4GB memory
    • Not implemented by all firmware
  • CPU caching
    • Without CPU caches everything is "slowmo" with usable system RAM
  • Every firmware has their own memory management implementation

RAM stage

  • Now we have full system memory!
    • Depending on the firmware <4GB
  • PCI device enumeration and resource allocation
  • Native graphics initialization
  • Option ROMs
  • Multi-Processor initialization
  • ACPI tables (ls /sys/firmware/acpi/tables/)
  • e820 table (cat /proc/iomem)
  • Device drivers (EC, TPM, etc..)
  • Firmware interfaces and runtime services

Bootloader

  • Most of the firmware include their own bootloader implementation
  • Some firmware like coreboot or hostboot doesn't include a bootloader but offer a payload loading mechanism
  • Jumps to the OS or another bootloader like (GRUB2, SHIM, EFI app)
  • Often can talk to the firmware via interfaces
  • Last step in the firmware boot process (OS Handoff)

PRE RAM

DRIVER LAYER

BOOTLOADER

Firmware Architecture

IBB

ROM stage

RAM stage

Open Source Firmware

OSF History

  • LinuxBIOS aka coreboot
    • Ronald Minnich
    • Stefan Reinauer
    • Since 1999
    • Started with x86 architecture

 

  • PPCBOOT aka Das U-Boot
    • Wolfgang Denk
    • Since 1999
    • Started with PowerPC architecture

Stefan Reinauer

Ronald Minnich

Wolfgang Denk

1981
First BIOS

by IBM

1998
Apple EFI by Intel

1999
coreboot, u-boot 

by OSF community

2008
TianoCore UEFI
by Intel

2006
UEFI by
Intel

2014
Hostboot

by IBM

2018
LinuxBoot

by Google

Closed Source Firmware

Open Source
Firmware

Firmware Timeline

Today

Why OSF?

  • Smaller companies producing hardware having trouble with high IBV royalty fees and SDK costs (OSHWA)
  • Closed source firmware is often terribly implemented by hardware companies not living in the present world of software development
  • Flexible solutions are required and fragmented firmware landscape making it difficult
    • High maintenance costs
    • Debugging is a pain in the ass

www.oshwa.org

Why OSF?

  • Features can be shared among companies with generalized implementations
  • Open Continuous Integration, tests, Quality Assurance and code review
    • Not perfect enough for products but helping making things more stable and less breaking the source code tree
  • Community as human resource for IBV/OEM companies
  • Free software licenses open up company contributions

Why OSF?

  • Security features need to be auditable and include documentation without reverse engineering the firmware
    • Measured boot functionality only makes sense on systems with reproducible firmware and insight into measurements. Think about firmware blobs!
    • Fixing firmware security issues is easier and doable by different entities
    • See Trammel Hudson talks about firmware security

We are fighting against blobs

  • Binary Large Objects in the firmware world are executable binaries containing obfuscated Intellectual Property code
  • Some blobs exposing an API interface or providing a header to parse its data
  • Most modern platforms require blobs in OSF, except
    • ​IBM openPOWER
    • SiFive RISC-V 
  • The so called "IP" code is often overrated but SoC vendors tend to lockdown their platform

Copyright by Scaleway, www.scaleway.com

We are fighting against blobs

  • SoC vendors fear to loose control over their PRE RAM platform initialization
    • ​IP code under NDA from different companies
    • "Secret bits" can break hardware
    • Every documentation is by default confidential
    • Conservative management and legal department
  • We have been fighting against blobs for ~20 years

PRE RAM

Intel FSP

AMD AGESA

Option ROM

Qualcomm TZ, DDR, CDT, RPM

Problems with IP code blobs

  • Massive code duplication by firmware blobs. No self maintenance possible
  • Hard to debug and understand because documentation is under NDA as well
  • Blob interfaces giving us trouble with FOSS licenses. Just saying firmware callbacks
  • Vendor support for firmware blobs is often limited
  • OSF often must be built around multiple blobs (code wrapper)

Required blobs

A modern Intel platform requires a huge amount of blobs

  • Microcode
  • FSP-T
  • FSP-M
  • FSP-S
  • Intel ME
  • Intel Audio
  • VGA Option ROMs

But they integrate their API interfaces into OSF!

Copyright by Intel, vzimmer.blogspot.com/2016/04/

OSF Projects

coreboot

  • Created by the community
  • Supports x86, ARM, ARM64, PPC64, RISC-V and more
  • Poor documentation
  • Big community
  • Public CI, review, and soon QA
  • Loads a payload after the hardware initialization:
    • SeaBIOS
    • GRUB2
    • TianoCore
    • U-Boot
    • LinuxBoot

www.coreboot.org

U-Boot

  • Created by the community
  • Supports x86, ARM, ARM64, PPC64, RISC-V and more
  • Documentation in GIT
  • Big community
  • Public CI and review but no QA
  • Contains own bootloader implementation
  • Supports EFI runtime/services and FIT payloads

www.denx.de/wiki/U-Boot

TianoCore

  • Started by Intel folks
  • UEFI specification and good documentation
  • ARM joined the project as well
  • Small community, no CI, and no QA:
    • Community Manager started a few months ago (Stephano Cetola)
  • Contains own bootloader implementation (BDS)
  • Project Mu by Microsoft  https://microsoft.github.io/mu/

www.tianocore.org

Hostboot

  • Started by IBM folks for openPOWER
  • PPC64 architecture support only
  • Most open firmware implementation of a SoC architecture 
  • Skiboot/Petitboot is loaded as payload
  • Good documentation
  • Community
  • No public CI or QA

github.com/open-power

And more...

  • ARM Trusted Firmware
    • Trusted Execution Environment
  • Slimbootloader
    • coreboot concept re-implementation in EFI code with BSD license
  • OpenBMC & u-bmc
    • Open Source BMC firmware
  • Sound Open Firmware project
    • Replacing DSP blobs for audio OSF support

Security Framework

  • UEFI Secure Boot
    • Microsoft Windows
    • Good documentation
    • Measured boot supported
    • UEFI support only
    • No library implementation for other firmware except UEFI modules
    • End user model included
    • Root of Trust is based on
      • SoC flash protection mechanisms
      • x509 certificates

www.uefi.org/specifications

Security Framework

  • Google Verified Boot
    • Utilized by coreboot, U-Boot and OpenBMC
    • No Measured boot support
    • Poor public documentation
    • Failure safety
    • Requires a lot flash memory storage because of multiple slots
    • C Library with tooling
    • Root of Trust is based on:
      • NOR flash protection mechanism
      • cryptographic keys

chromium.googlesource.com/chromiumos/platform/vboot/

An old idea for a new approach...

LinuxBoot

  • Started by Google folks in Q1/2017
  • GPLv2 and BSD licenses
  • Basic ideas
    • Make firmware driver development unnecessary by using a Linux kernel instead of the DRIVER LAYER
    • Easier to find new "firmware" developers
    • Less code duplication and well tested device drivers
    • The BOOTLOADER isn't needed anymore because it is part of LinuxBoot

www.linuxboot.org

PRE RAM

DRIVER LAYER
LINUX KERNEL

BOOTLOADER
LINUX USERSPACE

LinuxBoot Architecture

Firmware

coreboot, U-Boot, TianoCore, Hostboot

LinuxBoot

LinuxBoot

LinuxBoot TODO

  • PCI device enumeration and resource allocation.
    • CONFIG_PCI_REALLOC_ENABLE_AUTO
  • System Management Mode (x86) kernel driver is still missing
  • Native graphics is supported by providing the video bios table via the firmware on Intel devices
  • Kernel environment requirements
    • e820 table and ACPI is still missing
  • Bootloader concept and implementation
    • e.g. systemboot

u-root

  • Started by Google folks
  • Pure Golang initramfs generator
    • Similar to busybox concept with 108 supported commands
    • Does automatic library detection for binaries added to the initrd
    • Init system which supports systemd!
    • Multiboot v1 kexec support
  • UEFI tooling with Fiano toolset
  • coreboot firmware interface support
  • TPM software stack by github.com/systemboot/tpmtool

u-root.tk

systemboot

  • Started by Facebook folks
  • Golang based Open Source bootloader implementation
  • Based on u-root code base
  • Boot methods
    • Localboot
      • GRUB/GRUB2/Syslinux configs
    • Netboot
      • DHCP configuration boot URL
  • Supports verified and measured boot
  • Supports firmware variables
    • coreboot (VPD) only

www.systemboot.org

Conclusion

OSF Hardware

  • Open Compute Project
  • Facebook Open Cellular
  • Purism
  • Google Chromebooks
  • PC Engines APU
  • Scaleway
  • Raptor Computing Systems TALOS
  • Microsoft Surface
  • A massive amount of embedded boards

OSFC 2019

  • Open Source Firmware Conference 2019
  • Mid of September
  • Silicon Valley
  • OSFC 2018
    • Sponsors: Google, Intel, Facebook, ARM, Secunet, Siemens and openSUSE
    • Attendees: 150
    • Projects: coreboot, LinuxBoot,      U-Boot, ARM Trusted Firmware, TianoCore

 

35c3 OSF Assembly

  • 30 seats
  • Open Source Firmware flashing
  • Hardware lab & Workshops
  • Check out our DEMO setup and get in touch with the community of OSF projects like:
    • coreboot
    • TianoCore
    • U-Boot
    • LinuxBoot
    • Systemboot / u-root

    Feel free to join our OSF assembly!