Talos Secure Workstation

The world's first ATX-compatible, workstation-class mainboard for the IBM POWER8 processor.

Nov 21, 2016

Project update 10 of 15

A Word on Lockdown

Over the life of the Talos™ project, we’ve received a number of requests for a cheap, blob-free, mass-market board based on consumer devices, including calls to use Intel®, AMD Zen™, or even ARM® CPUs as the core of this new product. Unfortunately, no CPUs on the market today meet, or can ever be modified to meet, these strict criteria. In this article we attempt to explain in detail the current state of the market and why blob-free hardware is no longer available, and may never be available again, at both midrange performance and consumer pricing levels.

Definitions

Blob-free: Hardware that has source code available for every
compiled firmware, system, or other binary required to make the
system functional, from initial power application to a full
operating environment. Furthermore, to qualify, the end user must
be able to modify said source code, recompile it, and use it on the
hardware in question. Hardware with source code available, but that
requires a vendor-controlled cryptographic signature to be present,
does not qualify as blob-free because the vendor has become the sole
source of the compiled and signed blob(s) needed to make the
hardware function.

Overview

A modern computer is a very complex device, requiring a great deal of initialization and setup before control can even be handed to an operating system kernel. Traditionally, this initialization was handled on x86 machines by the BIOS (essentially, standardized boot firmware for the PC architecture), which was an unsigned, closed source application located in ROM or, later, Flash memory. Most hardware at the time (x86, ARM, POWER, etc.) started execution from the processor’s reset vector immediately after power on and reset release; as such, there was nothing stopping a project such as coreboot from creating and compiling its own libre initialization code, then writing the resultant firmware binary over the prorietary BIOS stored within the mainboard’s Flash memory — the hardware would simply execute whatever machine code was present at the reset vector, regardless of origin.

Over time, the amount of hardware the platform firmware needed to set up grew almost exponentially, eventually including cache setup, SMP initialization, DDR DRAM training, bus configuration, and many other highly complex functions. Coreboot was eventually unable to keep up with these ever-increasing requirements due to a lack of documentation from the silicon vendors, with AMD being a notable exception due to release of the associated BKDG documentation containing the information needed to properly initialize AMD platforms. As a result of this and several other factors, AMD hardware has been relatively well supported under coreboot for much of the project’s life. On the other hand, coreboot on Intel hardware has lagged or relied heavily on vendor blobs due to the reverse engineering required to natively set up Intel platforms with libre software. Unfortunately, both AMD and Intel now provide large, precompiled binary blobs for CPU and platform setup, and no longer provide any source code or reference materials needed to implement these setup stages. Due to the complexity of modern CPU and platform setup, this lack of documentation or functional source code has created a sort of "soft lockdown", one that, given enough time and developer effort, can still be worked around. Much of the libre software community has grown accustomed to this "soft lockdown", and is now used to developers routinely "freeing" hardware locked to proprietary software via these methods. (This should not be conflated with the far more serious hard lockdown discussed below.)

In addition to the platform firmware discussed, most CPUs contain microcode, which is a small chunk of gate-level hardware configuration data (horizontal microcode) or a small program running inside the CPU (vertical microcode) that controls how the CPU responds to complex instructions. All x86 CPUs contain a copy of the microcode burned into an on-die storage device, and furthermore can accept microcode updates on the fly via special instructions. Microcode may or may not pose a lockdown and/or security risk depending on the microcode type and CPU age. In general, the fact that microcode is a blob is largely ignored by the libre software community. Some architectures, such as POWER, have unsigned and relatively open microcode, while ARM is unique in that most implementations have no microcode at all.

TPMs and Trusted Boot

While the hardware designs discussed above are relatively simple in relation to firmware loading, basically executing from the reset vector on power application, and while they do allow for platform firmware modification, these characteristics are highly undesireable in the context of trusted computing. Essentially, if the platform firmware and, more importantly, the Core Root of Trust and Measurement (CRTM), can be modified at will, there is no way for software further along in the secure boot chain, including sensitive applications, to determine if a particular system has been tampered with by an unauthorized party. Tamper detection and subsequent application rejection is especially important in consumer level devices to enforce unbreakable Digital Rights Management (DRM) anti-features. For instance, the Palladium project started by Microsoft in April 2002, then renamed "Next-Generation Secure Computing Base" (NGSCB), relied on a known, trustworthy CRTM for its operation. In a nutshell, Palladium relied on hardware-enforced, application-specific ("curtained") memory along with a Trusted Platform Module (TPM) containing the decryption key for protected content. TPMs only unseal their key if certain measurements, taken during the boot process and stored in PCRs, match the preconfigured values. Base measurements are normally taken before control is passed to the operating system by the bootblock or other suitably low-level portion of the firmware, which contains the CRTM. Tampering with the CRTM could allow the TPM to "validate" tampered firmware or operating system components, rendering the entire TPM-based security model useless. The secure boot chain currently used in most computing products also relies on the CRTM being secure and unable to be modified, as modifications could allow booting of unverified or unauthorized firmware or operating system components.

Lockdown!

The simplest "sledgehammer" approach to securing the CRTM is to have the vendor cryptographically sign it, then add checks in the hardware to prevent anything other than the vendor-signed CRTM from executing. Given the CRTM location in the lowest levels of the platform firmware (often, in the bootblock or even the firmware for a dedicated coprocessor), this means that any hardware with a vendor-secured CRTM can never have libre replacement firmware written for it. Ever. The hardware won’t even start executing firmware that doesn’t pass the vendor cryptographic checks, full stop. Effectively, cryptography has become a double-edged sword; it is now being used to lock physical machine owners out of the hardware they ostensibly own, forcing them to either use firmware that often comes with a license agreement or return/discard the hardware entirely.

We have already seen numerous instances of this lockdown being used to prevent modification of platform firmware and operating system/user space software. Some of the most famous examples are the TiVo boxes from the late 1990s, most iPhone and iPod products, and a growing number of Android devices from cell phones to tablets. If a device manufacturer enables signature checks, in most cases the only recourse is to either accept the proprietary firmware and software stack as-is, thus completely ignoring the privacy, freedom, and ethical concerns associated with that stack, or to stop using the device as anything but a source of spare parts or a doorstop!

Consumer Device Status

As of this writing, all currently manufactured, low- to mid-range and higher x86 devices, with the exception of two obsolete AMD CPUs, incorporate a security processor that is cryptographically signed, updateable, unauditable, and for which no source code or documentation has been made public. Worse, these security processors must load and continually execute this signed firmware for the system to either be brought online (AMD) or for it to remain operational (Intel). Intel calls this technology the "Management Engine" (ME), and ships a network-enabled firmware stack for the custom OS running on the dedicated ME CPU, while AMD calls it the "Platform Security Processor" (PSP), and won’t even release the x86 cores from reset until the PSP has been started from its signed firmware blob. AMD has also incorporated the PSP into its ARM CPUs, rendering them useless for libre hardware. On the low end, some unlocked ARM devices are available, but either their I/O options are severely lacking or they are not designed for general purpose computing in the first place, rendering performance even worse than expected when used in this role. RISC-V is behind even ARM in terms of maturity with no shipping general-purpose silicon or public, reproducible benchmark data at this time. ARM-based libre systems may allow libre computing to survive in some form as a retrocomputing hobby, but they will not allow libre computing to retain its dominant role in shaping the modern software world that we have all not only grown so accustomed to, but have benefited greatly from.

As we mentioned in our presentation "The World Beyond x86", x86 is the only option available in the low to mid-range market segment. It is the only processor architecture used to manufacture CPUs that are both powerful enough to develop modern software and able to be used in systems retailing for below $1,000 USD. This is the fundamental reason that we, or anyone else, cannot offer libre systems in the price and performance class requested. Anyone claiming to be able to do so are either running a scam or severely distorting facts, and there have unfortunately been multiple public instances of this already, a result of feeding off people’s strong desire for said machines.

Why OpenPOWER?

POWER8, via the OpenPOWER initiative, is the only architecture currently being used to manufacture powerful CPUs that are not locked down with cryptographic signing keys or other restrictions. Furthermore, all firmware source code for OpenPOWER machines has been released, meaning that unlike x86 you don’t have to pay a third party to create libre firmware for POWER machines! POWER9, when released late next year, will continue this unprecedented level of open access to OpenPOWER systems, however without POWER8 based systems such as our Talos™ first, the only truly open production POWER9 systems may very well be high-end server machines with a $15,000 USD or higher retail price, as was the case for POWER8. Furthermore, as will be detailed in a future update, only Talos™ contains the novel security hardware required to not only enable fully owner-controlled secure boot, but mitigate hardware attacks and restore the TPM as a useful, owner-controlled platform integrity verification tool. As such, it is vital that the libre software community, and specifically those working on large projects like Chromium, the Linux kernel, Firefox, LibreOffice, gcc, clang, GIMP, MySQL, and Xorg, rallies behind the only libre hardware powerful enough to enable development of those projects. Unless this is done, and soon, libre software will slowly fade as we slowly accept a greater level of proprietary software just to retain access to machines capable of compiling these projects, and as more and more of libre software’s core functionality is taken over by the ever-expanding, proprietary platform firmware (which is currently an operating system or at least a hypervisor in is own right!).

Conclusion

As can be seen from the discussion above, the libre hardware situation is far more dire than commonly known. We are very much in danger of relegating libre software to execution within a sandboxed hypervisor environment or even as a set of licensed userspace tools only. Please help us avoid this future and bring Talos™ to market; even if you can’t afford a full Talos™ mainboard, please consider purchasing one of the SSH access options and help us make this powerful, truly libre system a reality!


Sign up to receive future updates for Talos Secure Workstation.

Subscribe to the Crowd Supply newsletter, highlighting the latest creators and projects