Uncorrectable freedom and security issues on x86 platforms

Timothy Pearson tpearson at raptorengineeringinc.com
Mon Apr 4 15:06:23 UTC 2016

Hash: SHA1


It has recently come to my attention that many in the free software
movement are unaware of a relatively new development on x86 platforms
that permanently removes the ability to use these platforms without also
continually executing signed, proprietary code at the highest possible
privilege level.  All post-2013 (AMD) and virtually all post-2009
(Intel) systems contain this mandatory technology, and therefore, by
design, can never be converted to run using pure FOSS.  Prior to these
changes projects such as coreboot could be used to replace the boot
firmware with a FOSS alternative.

The technologies in question are the Intel Management Engine (ME) and
the AMD Platform Security Processor (PSP).  Both serve effectively the
same purpose; to ensure that the physical owner of the machine never has
full control of said machine.  These technologies, in turn, are used to
implement various forms of remote control and Digital Rights Management
(DRM) technologies, including Secure Boot, which even now requires FOSS
users to purchase a license from Microsoft to boot FOSS on affected
machines that lack an appropriate Secure Boot override.  This includes,
for example, many newer laptops.  Major distributions have worked around
this issue by purchasing a signing key from Microsoft for their binary
packages, but the end user is unable to modify the signed software
without a license from Microsoft, even though they have the source code
available to them under the GPL.

Furthermore, these signed, proprietary, binary-only firmware blobs must
execute on the service processor(s) before the main x86 CPU cores are
even released from reset (AMD), or will hard reset the entire system
after around 30 minutes of non-operation (Intel).  These blobs continue
to operate on the service processor(s) as long as the system is powered
on, and in the case of the Intel ME they also continue to operate while
the system is powered off but still has access to power (e.g. plugged in
or charged battery attached).  These services processors have full
access to system memory and all system peripherals, effectively giving
the binary blobs executing on them a higher privilege level than even
the operating system kernel.  Due to the ability to access system
peripherals, these proprietary blobs could easily contain code to
exfiltrate encryption keys, remotely activate microphones and cameras,
plant unwanted data, or simply remotely disable the ability of the
machine to boot FOSS operating systems entirely.  Finally, the Intel ME
firmware can be forcibly updated by a remote entity; it is unknown
whether the AMD PSP contains similar functionality at this time.

So, what can an average user do?  The obvious answer is to simply switch
away from using the x86 architecture entirely.  As Intel owns all rights
to the x86 architecture, there will never be any new manufacturers
licensed to make x86 chips, and therefore there will never be any
competition to remove these DRM-laden antifeatures.  There are numerous
alternative architectures available, especially for those already using
software with the source code available (i.e. FOSS), all of which can be
licensed by other manufacturers should the need arise.

General Overview of Alternate Architectures
=== ARM ===

While the ARM architecture may be more wildly known for locked-down
computing products, there are several ARM devices on the market that
allow full FOSS replacement of the boot firmware.  Generally these are
laptops, tablets, and embedded systems, with one example laptop being
the ASUS C201 Chromebook:
Using ARM in a mobile form factor also provides advantages of low cost
and long battery life, albeit at the expense of overall system performance.

=== POWER ===

IBM has recently released their high-performance POWER8 architecture for
third party licensing, and has also released a small treasure trove of
firmware and documentation for these devices.  POWER is the only
architecture currently competitive with Intel in terms of raw
performance, and boots using a fully FOSS firmware with no DRM
antifeatures embedded.  The primary disadvantage of power is cost, as it
is currently targeted at the server and datacenter markets.  We are
attempting to bring POWER to the high-end workstation market in a
FOSS-friendly form via the Talos™ Secure Workstation, but need
additional interest to make this a reality:

=== MIPS ===

Less well known than ARM, and with less vendor choice, MIPS is often
overlooked.  However, China has revived this architecture for general
purpose computing with the Loongson core, and several machines are
available using this processor.  As a niche processor it has far worse
performance than even a low-end ARM processor, but marginally better
energy efficiency.  Not recommended in light of ARM and POWER8:

=== RISCV ===

While this architecture is extremely limited in performance, price, and
performance per watt compared to x86, ARM, or POWER, it is also one of
the only fully open source CPU architectures available outside of an
FPGA. and may eventually be competitive with MIPS in terms of raw
performance.  Currently there are no RISCV SoCs in production, however
projects such as lowRISC aim to change that:


So, what are your thoughts on the current x86 proprietary software
situation?  Are you willing to continue to use FOSS software inside the
ever-shrinking x86 "software jail", or are you possibly willing to give
up some cost or performance advantages in order to retain full control
of the software running on your hardware?  This is a question that will
need to be answered soon; the long-term consequences of a fully
TiVo-ized computing world are not to be taken lightly, and thus far the
free software community has put up very little resistance to the
antifeatures being forced into modern x86 platforms.  I hope to provoke
wider discussion on these topics via this message.

Thank you for your attention!

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Discussion mailing list