summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorPaul Menzel <pmenzel@molgen.mpg.de>2020-02-05 16:42:48 +0100
committerPatrick Georgi <pgeorgi@google.com>2020-02-09 19:23:58 +0000
commit75372e5a7541a897b7d41d062957d045a1021ff9 (patch)
tree81c455c797613e383a4006ce197e07d47dfec42e /Documentation
parentcedd4525f27694d55014c7d8df540fe409e9677f (diff)
Documentation: Mark up register names as code
Change-Id: I708385bca8edcd74b0d4c0a3ecc181b6ccd30c2b Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38721 Reviewed-by: Peter Lemenkov <lemenkov@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/mainboard/lenovo/ivb_internal_flashing.md30
1 files changed, 15 insertions, 15 deletions
diff --git a/Documentation/mainboard/lenovo/ivb_internal_flashing.md b/Documentation/mainboard/lenovo/ivb_internal_flashing.md
index 355cf98448..e6b597b284 100644
--- a/Documentation/mainboard/lenovo/ivb_internal_flashing.md
+++ b/Documentation/mainboard/lenovo/ivb_internal_flashing.md
@@ -5,9 +5,9 @@
Old versions of stock BIOS for these models have several security issues.
In order to flash coreboot internally, two of them are of interest.
-**First** is the fact the SMM_BWP and BLE are not enabled in BIOS
+**First** is the fact the `SMM_BWP` and `BLE` are not enabled in BIOS
versions released before 2014. We have tested many versions on T430 and
-X230 and found out that SMM_BWP=1 only since the update, the changelog
+X230 and found out that `SMM_BWP=1` only since the update, the changelog
of which contains following line:
> (New) Improved the UEFI BIOS security feature.
@@ -159,14 +159,14 @@ chip:
Configuration Registers. When set to 1, PR0-PR4 registers cannot be
written. Once set to 1, cannot be changed anymore.
-To be able to flash, we need SMM_BWP=0, BIOSWE=1, BLE=0, FLOCKDN=0 or
+To be able to flash, we need `SMM_BWP=0`, `BIOSWE=1`, `BLE=0`, `FLOCKDN=0` or
SPI protected ranges (PRx) to have a WP bit set to 0.
-Let's see what we have. Examine HSFS register:
+Let's see what we have. Examine `HSFS` register:
sudo chipsec_main -m chipsec.modules.common.spi_lock
-You should see that FLOCKDN=1:
+You should see that `FLOCKDN=1`:
[x][ =======================================================================
[x][ Module: SPI Flash Controller Configuration Locks
@@ -181,11 +181,11 @@ You should see that FLOCKDN=1:
[14] FDV = 1 << Flash Descriptor Valid
[15] FLOCKDN = 1 << Flash Configuration Lock-Down
-Then check BIOS_CNTL and PR0-PR4:
+Then check `BIOS_CNTL` and PR0-PR4:
sudo chipsec_main -m common.bios_wp
-Good news: on old BIOS versions, SMM_BWP=0 and BLE=0.
+Good news: on old BIOS versions, `SMM_BWP=0` and `BLE=0`.
Bad news: there are 4 write protected SPI ranges:
@@ -215,8 +215,8 @@ Other way to examine SPI configuration registers is to just dump SPIBAR:
sudo chipsec_util mmio dump SPIBAR
-You will see SPIBAR address (0xFED1F800) and registers (for example,
-00000004 is HSFS):
+You will see `SPIBAR` address (0xFED1F800) and registers (for example,
+`00000004` is `HSFS`):
[mmio] MMIO register range [0x00000000FED1F800:0x00000000FED1F800+00000200]:
+00000000: 0BFF0500
@@ -224,11 +224,11 @@ You will see SPIBAR address (0xFED1F800) and registers (for example,
...
As you can see, the only thing we need is to unset WP bit on PR0-PR4.
-But that cannot be done once FLOCKDN is set to 1.
+But that cannot be done once `FLOCKDN` is set to 1.
Now the fun part!
-FLOCKDN may only be cleared by a hardware reset, which includes S3
+`FLOCKDN` may only be cleared by a hardware reset, which includes S3
state. On S3 resume boot path, the chipset configuration has to be
restored and it's done by executing so-called S3 Boot Scripts. You can
dump these scripts by executing:
@@ -236,7 +236,7 @@ dump these scripts by executing:
sudo chipsec_util uefi s3bootscript
There are many entries. Along them, you can find instructions to write
-to HSFS (remember, we know that SPIBAR is 0xFED1F800):
+to `HSFS` (remember, we know that `SPIBAR` is 0xFED1F800):
Entry at offset 0x2B8F (len = 0x17, header len = 0x0):
Data:
@@ -251,7 +251,7 @@ to HSFS (remember, we know that SPIBAR is 0xFED1F800):
These scripts are stored in memory. The vulnerability is that we can
overwrite this memory, change these instructions and they will be
-executed on S3 resume. Once we patch that instruction to not set FLOCKDN
+executed on S3 resume. Once we patch that instruction to not set `FLOCKDN`
bit, we will be able to write to PR0-PR4 registers.
## Creating a backup
@@ -274,7 +274,7 @@ brick your machine, because your backup has `FF`s in place of `fd` and
## Removing protections (practice)
-The original boot script writes 0xE009 to HSFS. FLOCKDN is 15th bit, so
+The original boot script writes 0xE009 to `HSFS`. `FLOCKDN` is 15th bit, so
let's write 0x6009 instead:
sudo chipsec_main -m tools.uefi.s3script_modify -a replace_op,mmio_wr,0xFED1F804,0x6009,0x2
@@ -297,7 +297,7 @@ like this:
[*] After sleep/resume, check the value of register 0xFED1F804 is 0x6009
[+] PASSED: The script has been modified. Go to sleep..
-Now go to S3, then resume and check FLOCKDN. It should be 0:
+Now go to S3, then resume and check `FLOCKDN`. It should be 0:
sudo chipsec_main -m chipsec.modules.common.spi_lock