Is it a small tablet or large phone? Is it a phone or broadcast sensor? Is it a server or virtual desktop cluster? Is x86 emulating ARM, or vice-versa? Is Linux inspiring Windows, or the other way around? Is it microcode or hardware? Is it firmware or software? Is it microkernel or hypervisor? Is it a security or quality update? Is anything in my device the same as yesterday? When we observe our evolving devices and their remote services, what can we question and measure?
General Purpose vs. Special Purpose Ecosystems
The general-purpose computer now lives in a menagerie of special-purpose devices and information appliances. Yet software and hardware components within devices are increasingly flexible, blurring category boundaries. With hardware virtualization on x86 and ARM platforms, the ecosystems of multiple operating systems can coexist on a single device. Can a modular and extensible multi-vendor architecture compete with the profitability of vertically integrated products from a single vendor?
Operating systems evolved alongside applications for lucrative markets. PC desktops were driven by business productivity and media creation. Web browsers abstracted OS differences, as software revenue shifted to e-commerce, services, and advertising. Mobile devices added sensors, radios and hardware decoders for content and communication. Apple, now the most profitable computer company, vertically integrates software and services with sensors and hardware. Other companies monetize data, increasing demand for memory and storage optimization.
Some markets require security or safety certifications: automotive, aviation, marine, cross domain, industrial control, finance, energy, medical, and embedded devices. As software “eats the world,” how can we modernize vertical markets without the economies of scale seen in enterprise and consumer markets? One answer comes from device architectures based on hardware virtualization, Xen, disaggregation, OpenEmbedded Linux and measured launch. OpenXT derivatives use this extensible, open-source base to enforce policy for specialized applications on general-purpose hardware, while reusing interoperable components.
OpenEmbedded Linux supports a range of x86 and ARM devices, while Xen isolates operating systems and unikernels. Applications and drivers from multiple ecosystems can run concurrently, expanding technical and licensing options. Special-purpose software can be securely composed with general-purpose software in isolated VMs, anchored by a hardware-assisted root of trust defined by customer and OEM policies. This architecture allows specialist software vendors to share platform and hardware support costs, while supporting emerging and legacy software ecosystems that have different rates of change.
On the Shoulders of Hardware, Firmware and Software Developers
System Architecture, from NIST SP800-193 (Draft), Platform Firmware Resiliency
By the time a user-facing software application begins executing on a powered-on hardware device, an array of firmware and software is already running on the platform. Special-purpose applications’ security and safety assertions are dependent on platform firmware and the developers of a computing device’s “root of trust.”
If we consider the cosmological “Turtles All The Way Down” question for a computing device, the root of trust is the lowest-level combination of hardware, firmware and software that is initially trusted to perform critical security functions and persist state. Hardware components used in roots of trust include the TCG’s Trusted Platform Module (TPM), ARM’s TrustZone-enabled Trusted Execution Environment (TEE), Apple’s Secure Enclave co-processor (SEP), and Intel’s Management Engine (ME) in x86 CPUs. TPM 2.0 was approved as an ISO standard in 2015 and is widely available in 2017 devices.
TPMs enable key authentication, integrity measurement and remote attestation. TPM key generation uses a hardware random number generator, with private keys that never leave the chip. TPM integrity measurement functions ensure that sensitive data like private keys are only used by trusted code. When software is provisioned, its cryptographic hash is used to extend a chain of hashes in TPM Platform Configuration Registers (PCRs). When the device boots, sensitive data is only unsealed if measurements of running software can recreate the PCR hash chain that was present at the time of sealing. PCRs record the aggregate result of extending hashes, while the TPM Event Log records the hash chain.
Measurements are calculated by hardware, firmware and software external to the TPM. There are Static (SRTM) and Dynamic (DRTM) Roots of Trust for Measurement. SRTM begins at device boot when the BIOS boot block measures BIOS before execution. The BIOS then execute, extending configuration and option ROM measurements into static PCRs 0-7. TPM-aware boot loaders like TrustedGrub can extend a measurement chain from BIOS up to the Linux kernel. These software identity measurements enable relying parties to make trusted decisions within specific workflows.
DRTM enables “late launch” of a trusted environment from an untrusted one at an arbitrary time, using Intel’s Trusted Execution Technology (TXT) or AMD’s Secure Virtual Machine (SVM). With Intel TXT, the CPU instruction SENTER resets CPUs to a known state, clears dynamic PCRs 17-22 and validates the Intel SINIT ACM binary to measure Intel’s tboot MLE, which can then measure Xen, Linux or other components. In 2008, Carnegie Mellon’s Flicker used late launch to minimize the Trusted Computing Base (TCB) for isolated execution of sensitive code on AMD devices, during the interval between suspend/resume of untrusted Linux.
If DRTM enables launch of a trusted Xen or Linux environment without reboot, is SRTM still needed? Yes, because attacks are possible via privileged System Management Mode (SMM) firmware, UEFI Boot/Runtime Services, Intel ME firmware, or Intel Active Management Technology (AMT) firmware. Measurements for these components can be extended into static PCRs, to ensure they have not been modified since provisioning. In 2015, Intel released documentation and reference code for an SMI Transfer Monitor (STM), which can isolate SMM firmware on VT-capable systems. As of September 2017, an OEM-supported STM is not yet available to improve the security of Intel TXT.
Can customers secure devices while retaining control over firmware? UEFI Secure Boot requires a signed boot loader, but customers can define root certificates. Intel Boot Guard provides OEMs with validation of the BIOS boot block. Verified Boot requires a signed boot block and the OEM’s root certificate is fused into the CPU to restrict firmware. Measured Boot extends the boot block hash into a TPM PCR, where it can be used for measured launch of customer-selected firmware. Sadly, no OEM has yet shipped devices which implement ONLY the Measured Boot option of Boot Guard.
Measured Launch with Xen on General Purpose Devices
OpenXT 7.0 has entered release candidate status, with support for Kaby Lake devices, TPM 2.0, OE meta-measured, and forward seal (upgrade with pre-computed PCRs).
OpenXT 6.0 on a Dell T20 Haswell Xeon microserver, after adding a SATA controller, low-power AMD GPU and dual-port Broadcom NIC, can be configured with measured launch of Windows 7 GPU p/t, FreeNAS 9.3 SATA p/t, pfSense 2.3.4, Debian Wheezy, OpenBSD 6.0, and three NICs, one per passthrough driver VM.
Does this demonstrate a storage device, build server, firewall, middlebox, desktop, or all of the above? With architectures similar to Qubes and OpenXT derivatives, we can combine specialized applications with best-of-breed software from multiple ecosystems. A strength of one operating system can address the weakness of another.
Measurement and Complexity in Software Supply Chains
While ransomware trumpets cryptocurrency demands to shocked users, low-level malware often emulates Sherlock Holmes: the user sees no one. Malware authors modify code behavior in response to “our method of questioning”, simulating heisenbugs. As system architects pile abstractions, self-similarity appears as hardware, microcode, emulator, firmware, microkernel, hypervisor, operating system, virtual machine, namespace, nesting, runtime, and compiler expand onto neighboring territory. There are no silver bullets to neutralize these threats, but cryptographic measurement of source code and stateless components enables whitelisting and policy enforcement in multi-vendor supply chains.
Even for special-purpose devices, the user experience bar is defined by mass-market computing. Meanwhile, Moore’s Law is ending, ARM remains fragmented, x86 PC volume is flat, new co-processors and APIs multiply, threats mutate and demand for security expertise outpaces the talent pool. In vertical markets which need usable, securable and affordable special-purpose devices, Xen virtualization enables innovative applications to be economically integrated with measured, interoperable software components on general-purpose hardware. OpenXT is an open-source showcase for this scalable ecosystem. Further work is planned on reference architectures for measured disaggregation with Xen and OpenEmbedded Linux.
If you are interested in virtualization and security, watch my presentation from the 2017 Xen Project Summit and join the OpenXT and OpenEmbedded communities! If you are attending the 2017 Embedded Linux Conference Europe, visit the OpenXT measured launch demo at the Technical Showcase on October 23 and attend Matthew Garrett’s talk, “Making Trusted Boot Practical on Linux” on October 24.
