Anastasia Klimchuk has uploaded this change for review. ( https://review.coreboot.org/c/flashrom/+/82649?usp=email )
Change subject: doc: Convert ME and Intel docs ......................................................................
doc: Convert ME and Intel docs
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 --- D Documentation/mysteries_intel.txt M doc/user_docs/index.rst A doc/user_docs/management_engine.rst A doc/user_docs/misc_intel.rst 4 files changed, 252 insertions(+), 173 deletions(-)
git pull ssh://review.coreboot.org:29418/flashrom refs/changes/49/82649/1
diff --git a/Documentation/mysteries_intel.txt b/Documentation/mysteries_intel.txt deleted file mode 100644 index 088abb8..0000000 --- a/Documentation/mysteries_intel.txt +++ /dev/null @@ -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=dr... -[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 diff --git a/doc/user_docs/index.rst b/doc/user_docs/index.rst index 5bc93d1..b61567a 100644 --- a/doc/user_docs/index.rst +++ b/doc/user_docs/index.rst @@ -7,3 +7,5 @@ fw_updates_vs_spi_wp example_partial_wp chromebooks + management_engine + misc_intel diff --git a/doc/user_docs/management_engine.rst b/doc/user_docs/management_engine.rst new file mode 100644 index 0000000..f1cf3fc --- /dev/null +++ b/doc/user_docs/management_engine.rst @@ -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` diff --git a/doc/user_docs/misc_intel.rst b/doc/user_docs/misc_intel.rst new file mode 100644 index 0000000..dca535e --- /dev/null +++ b/doc/user_docs/misc_intel.rst @@ -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
-
Anastasia Klimchuk (Code Review)