Uncorrectable freedom and security issues on x86 platforms

[mmix]

http://mail.fsfeurope.org/pipermail/dis ... 10912.html
https://news.ycombinator.com/item?id=11422531

All,

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:
https://libreboot.org/docs/install/c201.html
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:
https://raptorengineeringinc.com/TALOS/prerelease.php

=== 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:
http://www.lemote.com/html/product/atx/2015/1227/8.html

=== 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:
http://www.lowrisc.org/

************************************************************************

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)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

[Crewp]

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?

I think you are preaching to the choir.

[Jedinovice]

I would love to go ARM but I need laptops now and ARM just isn't going laptop.

Also, I use a lot of software and I doubt the stuff I use is for ARM yet.

[LinuxJim]

Also, I use a lot of software and I doubt the stuff I use is for ARM yet.

Most Linux sotware is architecture-independent. It may not all be pre-packaged for ARM, but it can certainly be compiled to run on ARM. Exceptions are some of the more obscure emulators, and maybe a handful of games.

[Jedinovice]

Also, I use a lot of software and I doubt the stuff I use is for ARM yet.

Most Linux sotware is architecture-independent. It may not all be pre-packaged for ARM, but it can certainly be compiled to run on ARM. Exceptions are some of the more obscure emulators, and maybe a handful of games.

Thanks for the thought. However, there are a still few issues with ARM laptops.

1) I have been there with Slackware. Compiling code is not so bad but dependency handling is a nightmare! It's what pushed me over to Mint. (Do you know how may dependencies Abiword has??!

2) There s no credible ARM laptop and not likely to be. OK, one could install a large SD card in a Chromebook and use that I suppose but I live in Indonesia where I have not seen a single Chromebook. After all the, infrastructure to run a cloud only device is not here.

3) I am using the laptop my wife bought me and I am under a moral obligation to use it until it disintergrates. The laptop is still in warrenty so I won't be laptop hunting for a while! (Note, somehow it's ended up with my getting my four core, 4GB atom machine and me ended up with the 2GB, 2 core atom, but I am the one who does video editing! How did that happen??? )

[LinuxJim]

Thanks for the thought. However, there are a still few issues with ARM laptops.

1) I have been there with Slackware. Compiling code is not so bad but dependency handling is a nightmare! It's what pushed me over to Mint. (Do you know how may dependencies Abiword has??!

Oh yes, I understand. ARM is certainly not as "pain-free" as x86, simply because of the relative popularity. But things like the Raspberry Pi are changing this (slowly). Debian and NetBSD are really the only two options for ARM that come close to the typical x86 distro's 'ease-of-use'. You might give one of them a try.

2) There s no credible ARM laptop and not likely to be. OK, one could install a large SD card in a Chromebook and use that I suppose but I live in Indonesia where I have not seen a single Chromebook. After all the, infrastructure to run a cloud only device is not here.

Yeah, that's how it is right now, but I do see ARM laptops coming in the near future. When they will make it to Indonesia, I have no idea. Battery life alone is one of the driving forces. X86 keeps getting more power hungry, while ARM can run for hours on a pair of flashlight batteries...

[Jedinovice]

Yes, battery life is a major consideration for me. Although video editing benefits from fast processor, my primary needs are portability and battery life. This may change a bit though if plans for employment come through. We shall see. I would love to see ARM laptops though I understand that the new Intel Core-M chips are startlingly power efficient and may knock ARM out. Intel are trying very hard to get one over on ARM and, frankly, I see them doing it given their huge R&D. Intel are so confident in their new energy saving chips that they brought back the 'Atom' label (which they abandoned with my Atom chip, naming it a 'Celeron Mobile.')

But, of course, I am limited to this laptop until further notice! Still, it's dirt cheap, uses the slowest tech going but is proving very versatile and has over a years return to manufactuer warrenty left.

[Note: as I say to my students. "What if I were to spend $1,200 on a top of the range i7 laptop... and I drop it.]

[mike acker]

what are the odds in Vegas on how long this will last,-- DRM usually gets trashed in a day or so

[Habitual]

What a snooze-fest.

[LinuxJim]

what are the odds in Vegas on how long this will last,-- DRM usually gets trashed in a day or so

This is far more than DRM. These are features that are being embedded in the hardware (which means you can't alter or remove them) that will allow organizations like the FBI or CIA (or anyone else you can think of) to access your computer remotely with no possibility of that access being detected or traced - regardless of the operating system and software you're running.

[mike acker]

what are the odds in Vegas on how long this will last,-- DRM usually gets trashed in a day or so

This is far more than DRM. These are features that are being embedded in the hardware (which means you can't alter or remove them) that will allow organizations like the FBI or CIA (or anyone else you can think of) to access your computer remotely with no possibility of that access being detected or traced - regardless of the operating system and software you're running.

as I noted elsewhere earlier today-- commercial and government interests will hike through hell before they give up access and control over computers and networks.... guess we better hang onto any pre UEFI chips and MoBo we might have.... although it remains to be seen how serious this actually is.... if experience is a guide..... it's worse than we imagine.

The activity of such surveillance ( if this is a real threat -- I'm waiting to read more about this ) would certainly be detected though: it should be possible to route the subject computer thru an analyzer box using RJ45 connections..... this would facilitate a traffic analysis. such tools are probably available now-- for forensic purposes in threat analysis companies .

If memory serves the firmware behind UEFI is writable..... IF you have the key to sign the update.

in digging thru NewEgg for parts for my next build I noticed I couldn't find a non UEFI MoBo. A MoBo *might* offer "legacy BIOS" -- or it might not. The Spec. sheet at NewEgg didn't specify .... ( or if it does I need to look closer ) .

on second thought though -- i think this latest crap is being built into the CPUs by AMD & Intel..... which might mean we can figure out at what point this is incorporated into the chips.... e.g. AMD is coming out with a new ZEN line.... but maybe the older Athelon and Phenom chips might not have the surveillance firmware.

[mmix]

http://kestrelcomputer.github.io/kestrel/
https://en.wikipedia.org/wiki/Open-sour ... rdware#CPU

majority is nothing, only freedom is something.

Kestrel Computer Project
Aiming to build a full-stack, open source, and open hardware home computer.

No back doors. No hardware locks or encryption. Open hardware means you can completely understand the hardware.
No memberships in expensive special interest groups or trade organizations required to contribute peripherals.
No fear of bricking your computer trying to install the OS of your choice. Bootstrap process is fully disclosed.
Designed to empower and encourage the owner to learn about and even tweak the software and the hardware for their own benefit.
Built on 64-bit RISC-V-compatible processor technology.
Compatible with Digilent Nexys-2 FPGA development board.

[LinuxJim]

it should be possible to route the subject computer thru an analyzer box using RJ45 connections..... this would facilitate a traffic analysis. such tools are probably available now-- for forensic purposes in threat analysis companies .

Yes, certainly some external device could be used to detect and/or analyze unknown 'traffic' (wich may or may not be encrypted). The point was that the typical end user will have no such device, and will be incapable of using his computer to detect, trace, or even 'know' that such surveillance was happening.