openwrt/flashrom
1
0
Fork 0
mirror of https://review.coreboot.org/flashrom.git synced 2025-04-27 23:22:37 +02:00
Code Issues Releases Wiki Activity

doc: Convert ME and Intel docs

Browse Source 
ME page existed on wiki here https://wiki.flashrom.org/ME

The contents are mostly unchanged, but one broken kernel link is
removed from Intel doc.

Change-Id: I79af5674f3af9ca880e89becd6a272a2cf8ed599
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82649
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This commit is contained in:
Anastasia Klimchuk 2024-05-25 21:51:34 +10:00
parent e25129d9b6
commit 1ed95233e8
4 changed files with 252 additions and 173 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

173
Documentation/mysteries_intel.txt
View File

@ -1,173 +0,0 @@
= BBAR on ICH8 =
There is no sign of BBAR (BIOS Base Address Configuration Register) in the
public datasheet (or specification update) of the ICH8. Also, the offset of
that register has changed between ICH7 (SPIBAR + 50h) and ICH9 (SPIBAR +
A0h), so we have no clue if or where it is on ICH8. Out current policy is to
not touch it at all and assume/hope it is 0.
= Software Sequencing vs. Hardware Sequencing and the "Opaque flash chip" =
Software sequencing and hardware sequencing are two methods used to interface
with the SPI controller on Intel platforms. They can be selected using either
ich_spi_mode=swseq or ich_spi_mode=hwseq programmer parameters. Flashrom will
attempt to automatically detect which mode to use.
Software sequencing is the traditional method whereby software running on the
CPU handles most of the logic needed to interact with the flash chip. This
offers good flexibility since the user can utilize any opcode available in the
OPMENU registers, and OPMENU can be left unlocked or on coreboot-supported
platforms the owner of the system may program it for their needs before locking
it. Advanced or non-standard features of a chip such as write protection and
OTP may therefore be directly utilized by software.
Hardware sequencing is a newer method (since around 2011) whereby most of the
logic for interacting with the SPI flash chip is contained within the SPI
controller itself and software such as flashrom may only select a few operations
chosen by Intel via the Flash Cycle (FCYCLE) field. The chip must conform to
specifications from Intel for each chipset/PCH. The specs are given in the
"SPI Programming Guide" application note. See [SPI_PROG] cited at the bottom of
this document for an example.
Hardware sequencing simplifies things from a software perspective since the
software is guaranteed some minimal level of support and doesn't even need to
know the chip's ID or opcodes; it just needs to tell the SPI controller to
perform a type of transaction such as "read", "4k block erase", etc. Hence when
using hardware sequencing one will see "Opaque flash chip" as the chip's
description since software might not be able to identify the chip. The SPI
controller can combine multiple physical flash chips to logically appear as a
single large flash device, and in such cases it would not make sense for
flashrom to try to identify the chip.
In many non-Intel systems the software has full control of a generic SPI
controller where the software controls the SPI signals and also constructs the
data payload including pre-op (e.g. write enable latch), opcode, address, and
data. Intel SPI flash controllers are purpose-built for flash chip access and
the software does not control the hardware directly. This makes Intel SPI
controllers less flexible from a software standpoint, however there are some
benefits such as guaranteed atomicity and multi-master arbitration needed for
modern Intel platforms where the CPU and various microprocessors can share the
same flash chip.
= SMM BIOS Write Protection =
Sometimes a hardware vendor will enable "SMM BIOS Write Protect" (SMM_BWP)
in the firmware during boot time. The bits that control SMM_BWP are in the
BIOS_CNTL register in the LPC interface.
When enabled, the SPI flash can only be written when the system is operating in
in System Management Mode (SMM). In other words, only certain code that was
installed by the BIOS can write to the flash chip. Programs that run in OS
context such as flashrom can still read the flash chip, but cannot write to the
flash chip.
Flashrom will attempt to detect this and print a warning such as the following:
"Warning: BIOS region SMM protection is enabled!"
Many vendor-supplied firmware update utilities do not actually write to the ROM;
instead they transfer data to/from memory which is read/written by a routine
running in SMM and is responsible for writing to the firmware ROM. This causes
severe system performance degradataion since all processors must be in SMM
context (ring -2) instead of OS context (ring 0) while the firmware ROM is being
written.
= Accesses beyond region bounds in descriptor mode =
Intel's flash image tool will always expand the last region so that it covers
the whole flash chip, but some boards ship with a different configuration.
It seems that in descriptor mode all addresses outside the used regions can not
be accessed whatsoever. This is not specified anywhere publicly as far as we
could tell. flashrom does not handle this explicitly yet. It will just fail
when trying to touch an address outside of any region.
See also http://www.flashrom.org/pipermail/flashrom/2011-August/007606.html
= (Un)locking the ME region =
If the ME region is locked by the FRAP register in descriptor mode, the host
software is not allowed to read or write any address inside that region.
Although the chipset datasheets specify that "[t]he contents of this register
are that of the Flash Descriptor" [PANTHER], this is not entirely true.
The firmware has to fill at least some of the registers involved. It is not
known when they become read-only or any other details, but there is at least
one HM67-based board, that provides an user-changeable setting in the firmware
user interface to enable ME region updates that lead to a FRAP content that is
not equal to the descriptor region bits [NC9B].
There are different ways to unlock access:
- A pin strap: Flash Descriptor Security Override Strap (as indicated by the
Flash Descriptor Override Pin Strap Status (FDOPSS) in HSFS. That pin is
probably not accessible to end users on consumer boards (every Intel doc i
have seen stresses that this is for debugging in manufacturing only and
should not be available for end users).
The ME indicates this in bits [19:16] (Operation Mode) in the HFS register of
the HECI/MEI PCI device by setting them to 4 (SECOVR_JMPR) [MODE_CTRL].
- Intel Management Engine BIOS Extension (MEBx) Disable
This option may be available to end users on some boards usually accessible
by hitting ctrl+p after BIOS POST. Quote: "'Disabling' the Intel ME does not
really disable it: it causes the Intel ME code to be halted at an early stage
of the Intel ME's booting so that the system has no traffic originating from
the Intel ME on any of the buses." [MEBX] The ME indicates this in
bits [19:16] (Operation Mode) in the HFS register of the HECI/MEI PCI device
by setting them to 3 (Soft Temporary Disable) [MODE_CTRL].
- Previous to Ibex Peak/5 Series chipsets removing the DIMM from slot (or
channel?) #0 disables the ME completely, which may give the host access to
the ME region.
- HMRFPO (Host ME Region Flash Protection Override) Enable MEI command
This is the most interesting one because it allows to temporarily disable
the ME region protection by software. The ME indicates this in bits [19:16]
(Operation Mode) in the HFS register of the HECI/MEI PCI device by setting
them to 5 (SECOVER_MEI_MSG) [MODE_CTRL].
== MEI/HECI ==
Communication between the host software and the different services provided by
the ME is done via a packet-based protocol that uses MMIO transfers to one or
more virtual PCI devices. Upon this layer there exist various services that can
be used to read out hardware management values (e.g. temperatures, fan speeds
etc.). The lower levels of that protocol are well documented:
The locations/offsets of the PCI MMIO registers are noted in the chipset
datasheets. The actually communication is documented in a whitepaper [DCMI] and
an outdated as well as a current Linux kernel implementation (currently in
staging/ exist [KERNEL]. There exists a patch that re-implements this in user
space (as part of flashrom).
== Problems ==
The problem is that only very few higher level protocols are documented publicly,
especially the bunch of messages that contain the HMRFPO commands is probably
well protected and only documented in ME-specific docs and the BIOS writer's
guides. We are aware of a few leaked documents though that give us a few hints
about it, but nothing substantial regarding its implementation.
The documents are somewhat contradicting each other in various points which
might be due to factual changes in process of time or due to the different
capabilities of the ME firmwares, example:
Intel's Flash Programming Tool (FPT) "automatically stops ME writing to SPI
ME Region, to prevent both writing at the same time, causing data corruption." [ME8]
"FPT is not HMRFPO-capable, so needs [the help of the FDOPS pin] HDA_SDO if
used to update the ME Region." [SPS]
When looking at the various ME firmware editions (and different chipsets), things
get very unclear. Some docs say that HMRFPO needs to be sent before End-of-POST
(EOP), others say that the ME region can be updated in the field or that some
vendor tools use it for updates. This needs to be investigated further before
drawing any conclusion.
[PANTHER] Intel 7 Series Chipset Family Platform Controller Hub (PCH) Datasheet
Document Number: 326776, April 2012, page 857
[NC9B] Jetway NC9B flashrom v0.9.5.2-r1517 log with ME region unlocked.
NB: "FRAP 0e0f" vs. "FLMSTR1 0a0b".
http://paste.flashrom.org/view.php?id=1215
[MODE_CTRL] Client Platform Enabling Tour: Platform Software
Document Number: 439167, Revision 1.2, page 52
[MEBX] Intel Management Engine BIOS Extension (MEBX) User's Guide
Revision 1.2, Section 3.1 and 3.5
[DCMI] DCMI Host Interface Specification
Revision 1.0
[KERNEL] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/staging/mei;hb=HEAD
[SPI_PROG] Ibex Peak SPI Programming Guide
Document Number: 403598, Revision 1.3, page 79
[ME8] Manufacturing with Intel Management Engine (ME) Firmware 8.X on Intel 7 Series
Revision 2.0, page 59
[SPS] Manufacturing with Intel Management Engine (ME) on Intel C600 Series Chipset 1
for Romley Server 2 Platforms using Server Platform Services (SPS) Firmware
Revision 2.2, page 51

2
doc/user_docs/index.rst
View File

@ -7,3 +7,5 @@ Users documentation
fw_updates_vs_spi_wp fw_updates_vs_spi_wp
example_partial_wp example_partial_wp
chromebooks chromebooks
management_engine
misc_intel

45
doc/user_docs/management_engine.rst Normal file
View File

@ -0,0 +1,45 @@
======================
ME (Management Engine)
======================
ME stands for Management Engine (or Manageability Engine) and refers to an Embedded Controller found in Intel chipsets. It uses different versions
of an `ARC <http://en.wikipedia.org/wiki/ARC_International>`_ 32-bit microcontroller that runs its own operating system independently from the user's.
The ME has access to all kinds of buses which allows for out-of-band processing which is used for features
like `Active Management Technology <http://en.wikipedia.org/wiki/Intel_Active_Management_Technology>`_, but it makes it also a very interesting target for black hats.
The firmware it runs is secured by certificates stored in ROM, but it is a complex beast and it is very unlikely that there is
no `way around its security measures <http://invisiblethingslab.com/resources/misc09/Quest%20To%20The%20Core%20(public).pdf>`_ (intentional backdoors included).
For further details about the ME please see these excellent `slides by Igor Skochinsky <http://2012.ruxconbreakpoint.com/assets/Uploads/bpx/Breakpoint%202012%20Skochinsky.pdf>`_
and the `Security Evaluation of AMT by Vassilios Ververis <http://web.it.kth.se/~maguire/DEGREE-PROJECT-REPORTS/100402-Vassilios_Ververis-with-cover.pdf>`_.
Effects on flashrom
===================
The firmware of the ME usually shares the flash memory with the firmware of the host PC (BIOS/UEFI/coreboot).
The address space is separated into regions (similar to partitions on a harddisk). The first one (*Descriptor region*)
contains configuration data which contains something similar to a partition table and access rights for the different devices that can access the flash
(host CPU, ME, GbE controller). These restrictions are enforced by the chipset's SPI controller which is the main interface for flashrom
to access the flash chip(s) attached to the chipset. Intel recommends to set the descriptor region read-only and to forbid reads and writes to the ME region by the host CPU.
Writes by the host could interfere with the code running on the ME. This means that flashrom which runs on the host PC can not access
the ME firmware region of the flash at all in this configuration. flashrom detects that, warns the user and disables write access for safety reasons in that case.
Unlocking the ME region
=======================
There are a few ways to enable full access to the ME region, but they are not user friendly at all in general. Also, the Descriptor region is not affected by these actions,
so it is still not possible to access the complete flash memory even when the ME region is unlocked. For the different possibilities please see
the document :doc:`misc_intel`.
Suggested workarounds
=====================
* If you just want to update the proprietary firmware of the board use the vendor tool(s).
* If you need full access to the flash chip get an external programmer (see :doc:`/supported_hw/supported_prog/index`) and try in-circuit programming.
* If you only need to update the BIOS region, then you may use the options ``--ifd -i bios --noverify-all`` to write (and verify) only the BIOS region as described in the Intel flash descriptor.
.. todo:: Migrate page for in-circuit programming (ISP)
See also
========
* The respective `coreboot page on the management engine <http://www.coreboot.org/Intel_Management_Engine>`_
* :doc:`misc_intel`

205
doc/user_docs/misc_intel.rst Normal file
View File

@ -0,0 +1,205 @@
========================
Miscellaneous Intel info
========================
BBAR on ICH8
============
There is no sign of BBAR (BIOS Base Address Configuration Register) in the
public datasheet (or specification update) of the ICH8. Also, the offset of
that register has changed between ICH7 (SPIBAR + 50h) and ICH9 (SPIBAR +
A0h), so we have no clue if or where it is on ICH8. Out current policy is to
not touch it at all and assume/hope it is 0.
Software Sequencing vs. Hardware Sequencing and the "Opaque flash chip"
=======================================================================
Software sequencing and hardware sequencing are two methods used to interface
with the SPI controller on Intel platforms. They can be selected using either
ich_spi_mode=swseq or ich_spi_mode=hwseq programmer parameters. Flashrom will
attempt to automatically detect which mode to use.
Software sequencing is the traditional method whereby software running on the
CPU handles most of the logic needed to interact with the flash chip. This
offers good flexibility since the user can utilize any opcode available in the
OPMENU registers, and OPMENU can be left unlocked or on coreboot-supported
platforms the owner of the system may program it for their needs before locking
it. Advanced or non-standard features of a chip such as write protection and
OTP may therefore be directly utilized by software.
Hardware sequencing is a newer method (since around 2011) whereby most of the
logic for interacting with the SPI flash chip is contained within the SPI
controller itself and software such as flashrom may only select a few operations
chosen by Intel via the Flash Cycle (FCYCLE) field. The chip must conform to
specifications from Intel for each chipset/PCH. The specs are given in the
"SPI Programming Guide" application note. See [SPI_PROG] cited at the bottom of
this document for an example.
Hardware sequencing simplifies things from a software perspective since the
software is guaranteed some minimal level of support and doesn't even need to
know the chip's ID or opcodes; it just needs to tell the SPI controller to
perform a type of transaction such as "read", "4k block erase", etc. Hence when
using hardware sequencing one will see "Opaque flash chip" as the chip's
description since software might not be able to identify the chip. The SPI
controller can combine multiple physical flash chips to logically appear as a
single large flash device, and in such cases it would not make sense for
flashrom to try to identify the chip.
In many non-Intel systems the software has full control of a generic SPI
controller where the software controls the SPI signals and also constructs the
data payload including pre-op (e.g. write enable latch), opcode, address, and
data. Intel SPI flash controllers are purpose-built for flash chip access and
the software does not control the hardware directly. This makes Intel SPI
controllers less flexible from a software standpoint, however there are some
benefits such as guaranteed atomicity and multi-master arbitration needed for
modern Intel platforms where the CPU and various microprocessors can share the
same flash chip.
SMM BIOS Write Protection
=========================
Sometimes a hardware vendor will enable "SMM BIOS Write Protect" (SMM_BWP)
in the firmware during boot time. The bits that control SMM_BWP are in the
BIOS_CNTL register in the LPC interface.
When enabled, the SPI flash can only be written when the system is operating in
in System Management Mode (SMM). In other words, only certain code that was
installed by the BIOS can write to the flash chip. Programs that run in OS
context such as flashrom can still read the flash chip, but cannot write to the
flash chip.
Flashrom will attempt to detect this and print a warning such as the following:
"Warning: BIOS region SMM protection is enabled!"
Many vendor-supplied firmware update utilities do not actually write to the ROM;
instead they transfer data to/from memory which is read/written by a routine
running in SMM and is responsible for writing to the firmware ROM. This causes
severe system performance degradataion since all processors must be in SMM
context (ring -2) instead of OS context (ring 0) while the firmware ROM is being
written.
Accesses beyond region bounds in descriptor mode
================================================
Intel's flash image tool will always expand the last region so that it covers
the whole flash chip, but some boards ship with a different configuration.
It seems that in descriptor mode all addresses outside the used regions can not
be accessed whatsoever. This is not specified anywhere publicly as far as we
could tell. flashrom does not handle this explicitly yet. It will just fail
when trying to touch an address outside of any region.
See also http://www.flashrom.org/pipermail/flashrom/2011-August/007606.html
(Un)locking the ME region
=========================
If the ME region is locked by the FRAP register in descriptor mode, the host
software is not allowed to read or write any address inside that region.
Although the chipset datasheets specify that "[t]he contents of this register
are that of the Flash Descriptor" [PANTHER], this is not entirely true.
The firmware has to fill at least some of the registers involved. It is not
known when they become read-only or any other details, but there is at least
one HM67-based board, that provides an user-changeable setting in the firmware
user interface to enable ME region updates that lead to a FRAP content that is
not equal to the descriptor region bits [NC9B].
There are different ways to unlock access:
* A pin strap: Flash Descriptor Security Override Strap (as indicated by the
Flash Descriptor Override Pin Strap Status (FDOPSS) in HSFS. That pin is
probably not accessible to end users on consumer boards (every Intel doc i
have seen stresses that this is for debugging in manufacturing only and
should not be available for end users).
The ME indicates this in bits [19:16] (Operation Mode) in the HFS register of
the HECI/MEI PCI device by setting them to 4 (SECOVR_JMPR) [MODE_CTRL].
* Intel Management Engine BIOS Extension (MEBx) Disable
This option may be available to end users on some boards usually accessible
by hitting ctrl+p after BIOS POST. Quote: "'Disabling' the Intel ME does not
really disable it: it causes the Intel ME code to be halted at an early stage
of the Intel ME's booting so that the system has no traffic originating from
the Intel ME on any of the buses." [MEBX] The ME indicates this in
bits [19:16] (Operation Mode) in the HFS register of the HECI/MEI PCI device
by setting them to 3 (Soft Temporary Disable) [MODE_CTRL].
* Previous to Ibex Peak/5 Series chipsets removing the DIMM from slot (or
channel?) #0 disables the ME completely, which may give the host access to
the ME region.
* HMRFPO (Host ME Region Flash Protection Override) Enable MEI command
This is the most interesting one because it allows to temporarily disable
the ME region protection by software. The ME indicates this in bits [19:16]
(Operation Mode) in the HFS register of the HECI/MEI PCI device by setting
them to 5 (SECOVER_MEI_MSG) [MODE_CTRL].
MEI/HECI
========
Communication between the host software and the different services provided by
the ME is done via a packet-based protocol that uses MMIO transfers to one or
more virtual PCI devices. Upon this layer there exist various services that can
be used to read out hardware management values (e.g. temperatures, fan speeds
etc.). The lower levels of that protocol are well documented:
The locations/offsets of the PCI MMIO registers are noted in the chipset
datasheets. The actually communication is documented in a whitepaper [DCMI] and
an outdated as well as a current Linux kernel implementation (currently in
staging/ exist [KERNEL]. There exists a patch that re-implements this in user
space (as part of flashrom).
Problems
========
The problem is that only very few higher level protocols are documented publicly,
especially the bunch of messages that contain the HMRFPO commands is probably
well protected and only documented in ME-specific docs and the BIOS writer's
guides. We are aware of a few leaked documents though that give us a few hints
about it, but nothing substantial regarding its implementation.
The documents are somewhat contradicting each other in various points which
might be due to factual changes in process of time or due to the different
capabilities of the ME firmwares, example:
Intel's Flash Programming Tool (FPT) "automatically stops ME writing to SPI
ME Region, to prevent both writing at the same time, causing data corruption." [ME8]
"FPT is not HMRFPO-capable, so needs [the help of the FDOPS pin] HDA_SDO if
used to update the ME Region." [SPS]
When looking at the various ME firmware editions (and different chipsets), things
get very unclear. Some docs say that HMRFPO needs to be sent before End-of-POST
(EOP), others say that the ME region can be updated in the field or that some
vendor tools use it for updates. This needs to be investigated further before
drawing any conclusion.
[PANTHER]
Intel 7 Series Chipset Family Platform Controller Hub (PCH) Datasheet
Document Number: 326776, April 2012, page 857
[NC9B]
Jetway NC9B flashrom v0.9.5.2-r1517 log with ME region unlocked.
NB: "FRAP 0e0f" vs. "FLMSTR1 0a0b".
http://paste.flashrom.org/view.php?id=1215
[MODE_CTRL]
Client Platform Enabling Tour: Platform Software
Document Number: 439167, Revision 1.2, page 52
[MEBX]
Intel Management Engine BIOS Extension (MEBX) User's Guide
Revision 1.2, Section 3.1 and 3.5
[DCMI]
DCMI Host Interface Specification
Revision 1.0
[SPI_PROG]
Ibex Peak SPI Programming Guide
Document Number: 403598, Revision 1.3, page 79
[ME8]
Manufacturing with Intel Management Engine (ME) Firmware 8.X on Intel 7 Series
Revision 2.0, page 59
[SPS]
Manufacturing with Intel Management Engine (ME) on Intel C600 Series Chipset 1
for Romley Server 2 Platforms using Server Platform Services (SPS) Firmware
Revision 2.2, page 51