Group: Hardware/Restrictions/anti-freedom/Intel Management Engine

From LibrePlanet
< Group:Hardware‎ | Restrictions‎ | anti-freedom
Revision as of 22:22, 26 February 2020 by GNUtoo (talk | contribs) (remove coreboot specific cathegory)
Jump to: navigation, search

Introduction

See the on the management engine on the FSF website for some background on why it is an attack on users freedom.

In a nutshell:

  • The code it runs is nonfree
  • That code is signed and required for booting the computer on recent computers
  • It's designed to remove users control over their computers.
  • Depending on the configuration, it can enable system administrators having configured it to remote control computers.

Freedom and security issues

  • The code that is running inside the management engine is proprietary and signed. Therefore, it cannot easily be audited, tested, or replaced, except by those people with access to the relevant private keys, i.e. a handful of Intel staff (and possibly government agents).
  • The ME has access to a lot of things, see "physical capabilities" column below for more details.
  • In addition to obvious attack vectors (the ME could be used by an adversary to spy on the PC user, tamper with their documents, etc), it could also potentially be used to alter the contents of the motherboard's BIOS flash chip, thereby polluting Coreboot builds based upon extracting the contents of that flash chip.

Versions

ME firmware version Microarchitecture Chipset AMT versions ME firmware versions Applications Location Required modules Bit
N/A (ME predecessor) ICH7 1.0
  • AMT
82573E Gigabit Ethernet Controller[1] None ?
Q963[1] 2.0
  • AMT
Q965[1] 2.0 3.0[2]
  • AMT
  • No TPM
1st Gen Core:[3]
  • Nehalem?
  • Other?
  • AltMeDisable[5]
Nehalem[6] Q57 6.0[1] 6.0, 6.1 [7]
2nd Gen Core[3]
3rd Gen Core[3]
4th Gen Core[3]
5th Gen Core:[3]
  • Broadwell
  • Other?
Skylake
  • RBE
  • BUP
  • KERNEL
  • SYSLIB[4]
6th Gen Core[3]
7th Gen Core[3]

Where

Board Firmware Microarchitecture ME location and physical capabilities ME restrictions
Lenovo X60/X60s/X60T None. [8] I945 + ICH7
  • Inside the ethernet controller, disabled: no Ethernet controller fimrware. [8]
  • Disabled: No Ethernet controller fimrware. [8]
Lenovo T60
Lenovo x200 Me firmware with AMT and other modules GM45/GS45

The ME is inside the PCH, it:

  • Has access to the computer's memory/RAM
  • Controls the computer's original networking adapters
  • Signed firmware
  • The ME can be disabled (no Firmware is run by it).
Lenovo x201 Me firmware with AMT and other modules Nehalem
  • Signed firmware
  • If ME firmware is absent, the computer freezes about 30min after boot.
Packard Bell EasyNote LM85 (MS2290) ?
  • Signed firmware
Samsung Series 5 550 Chromebook me.bin Sandy Bridge
  • Signed firmware
Samsung Series 3 Chromebox me.bin
Lenovo t520 Me firmware with AMT and other modules
Google/HP Pavilion Chromebook 14 me.bin Ivy Bridge
  • Signed firmware
Google Chromebook Pixel me.bin
Google/Acer C7 Chromebook me.bin
Google/Lenovo Thinkpad X131e Chromebook me.bin
Lenovo t530 Me firmware with AMT and other modules
Lenovo x230 Me firmware with AMT and other modules
Kotron KTQM77/mITX ?
Google/Acer C720 Chromebook ? Haswell
  • Signed firmware
Google/HP Chromebook 14 ?

Reducing harm without fixing the issue

  • There are several versions of the Management Engine OS for a given Management Engine hardware. Smaller versions can contain less code.
  • me_cleaner can remove some of the Management Engine OS code.

However none of the above fixes the fact that nonfree code runs on hardware that has too many capability and that is meant to remove users control of their computer.

Research on removing the Management Engine OS

Removing the ME partition on platforms earlier than GM45

It's probably possible to remove the ME or AMT partitions on chipset before GM45 simply by not using the flash partition table.

Removing the ME partition on GM45

On The GM45 Chipset, the flash partition table can be configured to not have any ME partition. So it's possible to remove the ME firmware completely.

Though the ME probably has a bootrom, which probably hasn't been dumped for the GM45.

Removing the ME partition on post-GM45

Some computers, with more recent chipsets than GM45 are able to boot with the ME partition removed:

  • There are some interesting bug reports in the me_cleaner bug tracker. Some people have removed the Management Engine OS on computers with chipsets more recent than GM45, but Coreboot hasn't been ported yet on such computers.
  • There is a report of removing the Management Engine OS for an asus P55 Extreme, again Coreboot hasn't been ported yet to the computer.

To be added to Libreboot a computer would need at least:

  • To be supported in Coreboot or other boot software (u-boot, etc)
  • To be usable without nonfree software, like the CPU microcode
  • Not to have hardware issues that are only fixable from within the Management Engine: On GM45 Chipsets the method to remove the Management Engine firmware was supported by Intel even if it wasn't very well known publicly, before being used in free software projects.

When code on the Management Engine is strictly required to boot

All the following research and attempts would in addition need someone to write free software code running inside the Management Engine to boot the computer.

It's still unknown how much work this could be.

DCI

It is possible to get JTAG through what is called DCI.

The idea is that it may enable to create modchip-like computers to boot recent Intel computers.

However, last time I checked using DCI still require:

  • Nonfree software to be dowloaded from Intel website in trial version. The DCI / red unlock would need to be reimplemented as free software.
  • Another similar Intel computer to run that software. This also need to be replaced with USB3 SBC, or FPGA but the protocol that is on the modified USB cable is still unknown at this point.

It might also be used to understand more the Intel platforms, dump the ME bootrom? and find ways around the code signature?

GPIO33 / HDA?

On GM45, the GPIO33 location is known on the Thinkpad X200.

What really happens when this pin is grounded?

Does it also disable code signature on the Management Engine?

What happens between the different ME generations?

Upstream sustainability

Coreboot is removing many boards from new revisions of Coreboot.

Boards are typically removed because they weren't converted in time to new frameworks.

The issue is that one needs to already be involved in Coreboot development and follow very closely the mailing list, and what is happening to catch that early enough.

You could have less than one month to convert the code, if you don't catch it in time, especially because you are not contacted. It's up to you to follow what hapening upstream.

While this lower the maintenance burden, as the maintainers don't need to care about converting the older code to the new frameworks, we also need to take it into account when deciding which computers to focus work on.

Here's what I know on that so far:

  • The MAINTAINERS file has maintainers for specific computers. If a computer is maintained we probably have good enough assurance that it'll stick around.
  • It's possible to pay some companies to do the maintenance work, but I don't have much information on that yet.

Why does that matters

While Coreboot itself is not FSDG compliant and expect users to download and use nonfree software for being able to use it on many computers, it's still interesting to have code maintained there.

This then enables FSDG compliant Coreboot distributions like Libreboot or the deblobed versions of Coreboot published as part of the RYF initiative, to still be able to benefit from new developments and bugfixes upstream.

It also enables to build virtuous circles between non-FSDG compliant projects like Coreboot and downstream projects, where code can be maintained by the upstream project, even if the computers can't meet the RYF certification.

The x86 RYF laptops were made possible thanks to that kind of relationship: The fully free GPU initialization code was made by Ron Minnich for the Chromebook Pixel, which is a computer that is fatally flawed as it cannot even boot with free software as it requires a nonfree Management Engine firmware to boot. This code was then reused to get a fully free GPU initialization in Coreboot for the Thinkpad X60. Coreboot (once deblobbed) was then used to create Libreboot and make the first RYF laptops certified.

As compilers evolve, it's also important to still be able to build the source code without having to build very old compilers.

Other architectures

While not all computers using other architectures can even boot with fully free software, some can.

Using daily other CPU architectures like ARM, ppc64le, or RISCV can enable people to understand what is lacking on such architectures.

For instance:

  • Trisquel doesn't work on ARM yet
  • The Parabola ARM port doesn't have as many packages as x86_64
  • Replicant can't be compiled from ARM computers yet
  • If the tor-browser becomes FSDG compliant by removing its addons page, it's there are no releases for other architectures than x86 for GNU/Linux.

Working to fix common usability issues users find would be a good idea to get rid of the problem.

As for speed, other architectures are catching up or will catch up with the most powerful x86 computers that are RYF compliant at some point.

It's also now possible to do some benchmarks on that as a deblobbed version of the phoronix-test-suite was packaged in Parabola.

As for hardware support, we will probably have some RYF compliant System on a chip at some point, when the LIMA driver becomes good enough to be usable daily.

See also

References

Credits