docs/fingerprint: Format with mdformat

No content changes.

BRANCH=none
BUG=none
TEST=view in gitiles

Signed-off-by: Tom Hughes <tomhughes@chromium.org>
Change-Id: Ib723245b20c34c0b9c65128e10cebfdd0de27ff6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2254995
Commit-Queue: Craig Hesling <hesling@chromium.org>
Reviewed-by: Craig Hesling <hesling@chromium.org>

3 files changed, 57 insertions, 55 deletions

diff --git a/docs/fingerprint/fingerprint-authentication-design-doc.md b/docs/fingerprint/fingerprint-authentication-design-doc.md
index 7103239822..396fbfe8d0 100644
--- a/docs/fingerprint/fingerprint-authentication-design-doc.md
+++ b/docs/fingerprint/fingerprint-authentication-design-doc.md
@@ -91,12 +91,12 @@ There are two main objectives for potential attackers:
 
 ### Scalability
 
-For Eve, we [considered][Old Design Doc] using SGX as the SBP.
-However the complexity of the solution makes that option unattractive, both
-because of the amount of dev work required and because of the large resulting
-attack surface. It’s also exclusive to Intel, we would have to develop a
-completely different architecture for other platforms, which would add more dev
-work and increase the attack surface again.
+For Eve, we [considered][Old Design Doc] using SGX as the SBP. However the
+complexity of the solution makes that option unattractive, both because of the
+amount of dev work required and because of the large resulting attack surface.
+It’s also exclusive to Intel, we would have to develop a completely different
+architecture for other platforms, which would add more dev work and increase the
+attack surface again.
 
 ## Overview {#overview}
 
@@ -337,14 +337,14 @@ JSON files with the following fields:
 The content of the "data" field is the encrypted template that can be deciphered
 by the SBP.
 
-| Field Name | Field description  | Field size (bytes) | Field offset (bytes) |
-| ---------- | ------------------ | ------------------ | -------------------- |
-| Version    | Number describing the version of the file format. Set to 3 at launch. | 2 | 0 |
-| Reserved   | Reserved bytes, set to 0 | 2 | 2 |
-| Nonce      | Randomly-generated IV | 12 | 4 |
-| Salt       | Randomly-generated salt | 16 | 16 |
-| Tag        | AES-GCM Authentication Tag | 16 | 32 |
-| Template   | Encrypted template | 47552 | 48 |
+Field Name | Field description                                                     | Field size (bytes) | Field offset (bytes)
+---------- | --------------------------------------------------------------------- | ------------------ | --------------------
+Version    | Number describing the version of the file format. Set to 3 at launch. | 2                  | 0
+Reserved   | Reserved bytes, set to 0                                              | 2                  | 2
+Nonce      | Randomly-generated IV                                                 | 12                 | 4
+Salt       | Randomly-generated salt                                               | 16                 | 16
+Tag        | AES-GCM Authentication Tag                                            | 16                 | 32
+Template   | Encrypted template                                                    | 47552              | 48
 
 When the user logs in, the cryptohome daemon store folder of that user is
 mounted and the JSON files become available to biod. For every enrolled finger,
@@ -761,8 +761,9 @@ The log file is `/var/log/cros_fp.log`.
 
 <!-- https://docs.google.com/drawings/d/1-JUWTF7sUTND29BfhDvIudzX_S6g-iwoxG1InPedmVw -->
 [Decryption Flowchart]: ../images/cros_fingerprint_decryption_flowchart.png
+
 <!-- https://drive.google.com/open?id=1uUprgLsTUZZ2G2QWRYcRn6zBAh6ejvJagVRD7eZQv-k -->
 [Encryption Flowchart]: ../images/cros_fingerprint_encryption_flowchart.png
+
 <!-- https://docs.google.com/drawings/d/1DFEdxfDXEtYY3LNOOJFAxVw2A7rKouH98tnb1yiXLAA -->
 [Fingerprint Architecture]: ../images/cros_fingerprint_architecture_diagram.png
-
diff --git a/docs/fingerprint/fingerprint-dev-for-partners.md b/docs/fingerprint/fingerprint-dev-for-partners.md
index 130127905d..131d7d7537 100644
--- a/docs/fingerprint/fingerprint-dev-for-partners.md
+++ b/docs/fingerprint/fingerprint-dev-for-partners.md
@@ -28,7 +28,7 @@ fingerprint-related functionality (matching, encryption, etc). The fingerprint
 sensor itself connects to the FPMCU board.
 
 This FPMCU board is the Dragonclaw Rev 0.2. |
---------------------------------------------|
+------------------------------------------- |
 ![Dragonclaw board]                         |
 
 
@@ -57,12 +57,12 @@ debug a running program. It supports SPI, UART, I2C, as well as JTAG/SWD.
 There are two different servo debugger setups supported, the
 [Servo Micro](#servo-micro) and the [Servo V2 + Yoshi](#servo-v2-yoshi). The
 servo micro is recommended for its simplicity. It lacks builtin JTAG/SWD support
-for single step debugging, but Dragonclaw v0.2 has an [SWD
-connector](#servo-micro-swd) that can be used.
+for single step debugging, but Dragonclaw v0.2 has an
+[SWD connector](#servo-micro-swd) that can be used.
 
-| [Servo Micro](#servo-micro) | [ServoV2 + Yoshi](#servo-v2-yoshi)        |
-| --------------------------- | ----------------------------------------- |
-| ![Servo Micro]              | ServoV2 ![Servo v2] Yoshi Flex ![Standard Yoshi Flex] |
+[Servo Micro](#servo-micro) | [ServoV2 + Yoshi](#servo-v2-yoshi)
+--------------------------- | ----------------------------------
+![Servo Micro]              | ServoV2 ![Servo v2] Yoshi Flex ![Standard Yoshi Flex]
 
 *** note
 For more information about both servos, see [servo].
@@ -86,7 +86,6 @@ For more information about Servo Micro, see [Servo Micro Info].
 
 Instructions for setup are described in [Fingerprint Debugging].
 
-
 ### Servo V2 + Yoshi
 
 Servo V2 is the original full featured debugger. It requires a
@@ -156,7 +155,7 @@ development machine.
 *   Create and [enter the `chroot`].
     *   You can stop after the `enter the chroot` step.
 
-### Build the [EC] (embedded controller) codebase
+### Build the [EC]\ (embedded controller) codebase
 
 Open **two** terminals and enter the chroot in each:
 
@@ -284,6 +283,7 @@ Flash the firmware file:
 ```
 
 Prepare a serial terminal in your chroot:
+
 ```bash
 (chroot) $ sudo emerge screen
 ```
@@ -455,9 +455,9 @@ tracked by multiple people and a record is preserved for posterity.
 
 ## Working with Chromebooks
 
-Chromebooks have an FPMCU (e.g., Dragonclaw) board attached to the
-motherboard. You can use the device to run `ectool` commands and test the
-fingerprint sensor from the UI.
+Chromebooks have an FPMCU (e.g., Dragonclaw) board attached to the motherboard.
+You can use the device to run `ectool` commands and test the fingerprint sensor
+from the UI.
 
 ### Developer Mode and Write Protection
 
@@ -514,11 +514,13 @@ From the DUT, flash the firmware you copied:
 ### Dragonclaw Rev 0.2 Rework {#dragonclaw-rev-0.2-rework}
 
 *** note
-**NOTE**: All Dragonclaw v0.2 boards have been reworked, so it is not necessary to perform the rework yourself.
+**NOTE**: All Dragonclaw v0.2 boards have been reworked, so it is not necessary
+to perform the rework yourself.
 ***
+
 Dragonclaw **Rev 0.2** has two load switches (`U4` and `U6`) that enable the
-1.8V power rail from the servo connector or motherboard connector. However,
-this switch is not compatible with 1.8V, so will always output 0V.
+1.8V power rail from the servo connector or motherboard connector. However, this
+switch is not compatible with 1.8V, so will always output 0V.
 
 The [rework document][Dragonclaw Rev 0.2 1.8V Rework] describes replacing these
 two switches with ones compatible with 1.8V.
diff --git a/docs/fingerprint/fingerprint.md b/docs/fingerprint/fingerprint.md
index fc61f08afc..cd6325c776 100644
--- a/docs/fingerprint/fingerprint.md
+++ b/docs/fingerprint/fingerprint.md
@@ -25,11 +25,11 @@ The following "boards" (specified by the `BOARD` environment variable when
 building the EC code) are for fingerprint:
 
 *   [`nocturne_fp`] aka [`nami_fp`] aka [`dartmonkey`]
-    *   Based on [STM32H743] (Cortex-M7).
+    *   Based on [STM32H743](Cortex-M7).
 *   [`hatch_fp`] aka [`bloonchipper`]
-    *   Based on [STM32F412] (Cortex-M4).
-    *   Support for the STM32F412 for the FPMCU is not yet fully complete,
-        but it is functional enough for testing.
+    *   Based on [STM32F412](Cortex-M4).
+    *   Support for the STM32F412 for the FPMCU is not yet fully complete, but
+        it is functional enough for testing.
 
 ### Determining Hardware {#chromeos-config-fingerprint}
 
@@ -115,8 +115,7 @@ See the [Unit Tests] documentation for details on how to [run the unit tests].
 them to disk. [`timberslide`] reads from sysfs, where the kernel driver
 [periodically dumps the FPMCU console output][cros_ec_debugfs]. [`timberslide`]
 writes the resulting logs to `/var/log/cros_fp.log`. There are multiple
-instances of [`timberslide`] that run; one for each MCU running the EC
-codebase.
+instances of [`timberslide`] that run; one for each MCU running the EC codebase.
 
 ### Starting timberslide
 
@@ -202,18 +201,17 @@ possible to update the public key stored in the RO firmware once a device has
 been shipped (i.e., once [hardware write protection] is enabled).
 
 Different keys are used to sign the firmware during development and production.
-The `dev` key is used for local builds and development and is not private; it
-is called `dev_key.pem` and located in the "board" directory for the given
-FPMCU (e.g., [`board/nocturne_fp/dev_key.pem`]). After doing a build, the
-`ec.bin` in the `build` directory (e.g., `build/nocturne_fp/ec.bin`) will be
-signed with the `dev` key.
-
-The two other types of keys are `premp` and `mp`, which stand for
-"pre-mass production" and "mass production", respectively. Both the `premp` and
-`mp` keys are only available to the buildbots as part of the official build.
-The `premp` is typically used during bringup of new hardware to validate the
-signing flow of the buildbots, while the `mp` key is used for PVT and production
-devices.
+The `dev` key is used for local builds and development and is not private; it is
+called `dev_key.pem` and located in the "board" directory for the given FPMCU
+(e.g., [`board/nocturne_fp/dev_key.pem`]). After doing a build, the `ec.bin` in
+the `build` directory (e.g., `build/nocturne_fp/ec.bin`) will be signed with the
+`dev` key.
+
+The two other types of keys are `premp` and `mp`, which stand for "pre-mass
+production" and "mass production", respectively. Both the `premp` and `mp` keys
+are only available to the buildbots as part of the official build. The `premp`
+is typically used during bringup of new hardware to validate the signing flow of
+the buildbots, while the `mp` key is used for PVT and production devices.
 
 Switching keys is only possible when the `RO` firmware is not write protected,
 since the public portion of the keypair is stored in the `RO` firmware.
@@ -221,6 +219,7 @@ since the public portion of the keypair is stored in the `RO` firmware.
 ### Generate Key
 
 For testing, you can generate a new key by using the following openssl command:
+
 ```bash
 openssl genrsa -3 -out board/$BOARD/dev_key.pem 3072
 ```
@@ -233,8 +232,8 @@ openssl genrsa -3 -out board/$BOARD/dev_key.pem 3072
 
 ## Signing
 
-[`futility`] is used to sign EC firmware. There’s a wrapper script around it
-for signing called [`sign_official_build.sh`].
+[`futility`] is used to sign EC firmware. There’s a wrapper script around it for
+signing called [`sign_official_build.sh`].
 
 ### Key ID
 
@@ -291,9 +290,9 @@ Signature verification succeeded.
 
 ### Showing Key ID (fingerprint) for running FW
 
-[Asked on chromeos-chatty-firmware][chatty-firmware-q]
-about adding an EC command to show the Key ID (fingerprint) from the RO version.
-This would make it a lot easier during both development and testing.
+[Asked on chromeos-chatty-firmware][chatty-firmware-q] about adding an EC
+command to show the Key ID (fingerprint) from the RO version. This would make it
+a lot easier during both development and testing.
 
 ## Power
 
@@ -409,9 +408,9 @@ bloonchipper_v2.0.2626-3c315108.bin  dartmonkey_v2.0.2887-311310808.bin
 ```
 
 The above output assumes you selected the `bloonchipper` and `dartmonkey`
-firmware by setting `FPMCU_FIRMWARE="bloonchipper dartmonkey"`.
-The actual version numbers displayed will not necessarily match since the
-firmware is constantly updated.
+firmware by setting `FPMCU_FIRMWARE="bloonchipper dartmonkey"`. The actual
+version numbers displayed will not necessarily match since the firmware is
+constantly updated.
 
 ### Update Chrome OS Config {#update-chromeos-config}