[doc] Remove Hugo-style heading IDs

The old Hugo documentation would set IDs for Markdown headings using {#id}
syntax. Mdbook will assign IDs automatically from the heading text.

Signed-off-by: James Wainwright <[email protected]>

Author: jwnrt

doc/contributing/hw/comportability/README.md

@@ -163,7 +163,7 @@ By "care" an example would be to reset their value synchronously at a time after
 
 Based upon this and the fact that much of the team history was with asynchronous active low reset, we chose that methodology with added requirements that special care be applied for security state, the details of which will come at a later date.
 
-### Bus Interfaces {#bus-interfaces}
+### Bus Interfaces
 
 Peripherals can connect to the chip bus.
 All peripherals are assumed to have registers, and are thus required to expose at least one device interface on the chip bus.
@@ -245,7 +245,7 @@ The connection between the modules are defined in the top-level configuration fi
 
 See the section on [Inter Signal Handling](#inter-signal-handling) below for detailed data structure in the configuration file.
 
-### Security countermeasures {#countermeasures}
+### Security countermeasures
 
 If this IP block is considered security-critical, it will probably have design features that try to mitigate against attacks like fault injection or side channel analysis.
 These features can be loosely categorised and named with identifiers of the following form:
@@ -444,7 +444,7 @@ This is done with a list with key `countermeasures`.
 Each item is a dictionary with keys `name` and `desc`.
 The `desc` field is a human-readable description of the countermeasure.
 The `name` field should be either of the form `ASSET.CM_TYPE` or `INSTANCE.ASSET.CM_TYPE`.
-Here, `ASSET` and `CM_TYPE` should be one of the values given in the tables in the [Security countermeasures](#countermeasures) section.
+Here, `ASSET` and `CM_TYPE` should be one of the values given in the tables in the [Security countermeasures](#security-countermeasures) section.
 If specified, `INSTANCE` should name a submodule of the IP block holding the asset.
 It can be used to disambiguate in situations such as where there are two different keys that are protected with different countermeasures.
 

doc/contributing/style_guides/c_cpp_coding_style.md

@@ -262,9 +262,9 @@ X macros that are not part of a header's API should be `#undef`ed after they are
 Similarly, the arguments to an X macro, if they are defined in a header, should be `#undef`ed too.
 This is not necessary in a `.c` or `.cc` file, where this cannot cause downstream namespace pollution.
 
-## C++ Style Guide {#cxx-style-guide}
+## C++ Style Guide
 
-### C++ Version {#cxx-version}
+### C++ Version
 
 C++ code should target C++14.
 

doc/guides/getting_started/src/build_sw.md

@@ -300,15 +300,15 @@ riscv32-unknown-elf-objdump --disassemble-all --headers --line-numbers --source
 
 Refer to the output of `riscv32-unknown-elf-objdump --help` for a full list of options.
 
-## Troubleshooting {#troubleshooting}
+## Troubleshooting
 
-### Check CI {#troubleshooting-check-ci}
+### Check CI
 
 First, [check the GitHub repository](https://github.com/lowRISC/opentitan/commits/master) to make sure the CI check is succeeding for the commit you cloned.
 If there's an issue with that commit (it would have a red "X" next to it), check out the most recent commit that passed CI (indicated by a green check mark).
 We try to always keep the main branch healthy, but the project is in active development and we're not immune to temporary breaks.
 
-### Debugging a failed verilator test {#troubleshooting-verilator-test-failure}
+### Debugging a failed verilator test
 
 If your `bazelisk.sh` build failed trying to run a test on Verilator, the first step is to see if you can build the chip simulation on its own:
 

doc/guides/getting_started/src/setup_fpga.md

@@ -148,7 +148,7 @@ You will then need to run this command to configure the board. You only need to
 bazel run //sw/host/opentitantool -- --interface=cw310 fpga set-pll
 ```
 
-Check that it's working by [running the demo](#hello-world-demo) or a test, such as the `uart_smoketest` below.
+Check that it's working by [running the demo](#bootstrapping-the-demo-software) or a test, such as the `uart_smoketest` below.
 ```console
 cd $REPO_TOP
 bazel test --test_output=streamed //sw/device/tests:uart_smoketest_fpga_cw310_test_rom
@@ -245,7 +245,7 @@ I00001 test_rom.c:87] TestROM:6b2ca9a1
 I00002 test_rom.c:118] Test ROM complete, jumping to flash!
 ```
 
-#### Bootstrapping the demo software {#hello-world-demo}
+#### Bootstrapping the demo software
 
 The `hello_world` demo software shows off some capabilities of the OpenTitan hardware.
 To load `hello_world` into the FPGA on the ChipWhisperer CW310 board follow the steps shown below.

doc/rust_for_c_devs.md

@@ -56,7 +56,7 @@ Identity is used to attest the owner and BL0 configuration, as well as an
 attestation key used by the Kernel. This key is endorsed by the Creator Identity,
 but can also be endorsed by the Silicon Owner PKI. Endorsement of the Owner
 Identity with the Owner's PKI, is covered in detail in the
-[Owner Personalization](../device_provisioning/README.md#owner_personalization) process
+[Owner Personalization](../device_provisioning/README.md#owner-personalization) process
 described in the provisioning specification.
 
 When using a Silicon Owner PKI, the Owner is expected to maintain a device
@@ -366,13 +366,13 @@ source with a security strength equivalent to the one supported by the key
 manager. The triggering mechanism for updating the value is covered in the
 [Attestation Updates](#attestation-updates) section.
 
-## Asymmetric Keys {#asymmetric-keys}
+## Asymmetric Keys
 
 OpenTitan uses ECDSA attestation keys conformant to
 [FIPS 186-4](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf). Future
 revisions of this specification may add support for other signature schemes.
 
-### Key Identifiers {#key-identifiers}
+### Key Identifiers
 
 Key identifiers are defined as follows, where `SALT_CKI`and `SALT_OKI` are 256b
 values defined in `ROM_EXT` and `BL0` respectively.
@@ -629,7 +629,7 @@ OpenTitan Creator Identity custom extension:
   </tr>
 </table>
 
-#### Creator custom Extension {#creator-custom-extension}
+#### Creator custom extension
 
 This extension is formatted as an ASN.1 SEQUENCE containing device identifiable
 information. See [Privacy Considerations](#privacy-considerations) for
@@ -829,7 +829,7 @@ custom extensions.
 The binary manifest format must be standardized at the OpenTitan project level
 to ensure interoperability between silicon and software layers.
 
-## Privacy Considerations {#privacy-considerations}
+## Privacy Considerations
 
 The Silicon Owner software must address any privacy concerns associated with the
 use of device identifiable information.
@@ -870,4 +870,4 @@ DICE terminology.
 [diversification-key]:../identities_and_root_keys/README.md#diversification-key
 
 [device-provisioning]: ../device_provisioning/README.md
-[owner-personalization]: ../device_provisioning/README.md#owner_personalization
+[owner-personalization]: ../device_provisioning/README.md#owner-personalization

doc/security/specs/attestation/README.md

@@ -15,7 +15,7 @@ two stages:
     [Creator Identity][creator_identity], its endorsement certificate, as well
     as additional secrets required to configure defensive mechanisms. This
     occurs only at manufacturing time.
-*   [Owner Personalization](#owner_personalization): Covers provisioning of
+*   [Owner Personalization](#owner-personalization): Covers provisioning of
     owner secrets and endorsement of the Owner Identity by the Silicon Owner.
     This may occur either at manufacturing time or as part of a later in-field
     ownership transfer.
@@ -48,7 +48,7 @@ requirements:
 
 ## Device Lifecycle and Personalization Stages
 
-### Unlock Tokens {#unlock_tokens}
+### Unlock Tokens
 
 OpenTitan provides a set of lock/unlock tokens to control the state of the
 device in early manufacturing stages. See
@@ -104,7 +104,7 @@ personalization.
 *   `PERSONALIZATION`: See [Personalization](#personalization) section for more
 *   `LOAD FW IMAGE`: Load factory image payload.
 
-## Personalization {#personalization}
+## Personalization
 
 ### Test Setup
 
@@ -185,7 +185,7 @@ flow with emphasis on the personalization process.
 Steps:
 
 1.  [Device identifiers][device_id] (`device_id`) and
-    [unlock tokens](#unlock_tokens) are programmed into the device's One Time
+    [unlock tokens](#unlock-tokens) are programmed into the device's One Time
     Programmable (OTP) memory. The unlock tokens are delivered in cleartext form
     to each OpenTitan die.
 2.  (Optional) A provisioning appliance collects all device identifiers and
@@ -203,15 +203,15 @@ Steps:
             generates `device_secrets` (in the injection case) and endorsement
             certificates. `appliance_secrets` are used to enable signing on
             endorsement certificates with Silicon Creator intermediate CA keys.
-        2.  [Self-Generated Process](#self_generated_process): The device
+        2.  [Self-Generated Process](#self-generated-process): The device
             generates its own `device_secrets` and the provisioning appliance is
             used to sign the endorsement certificate.
 6.  At the end of a successful provisioning flow, the provisioning appliance
     sends the device certificates to a device registry. Silicon Owners can use
     the registry as part of identity ingestion flows.
 7.  The devices are shipped with a factory image and a Silicon Creator
     endorsement certificate. The Silicon Creator may also provide
-    [Owner Personalization](#owner_personalization) services. All shipped
+    [Owner Personalization](#owner-personalization) services. All shipped
     devices have secure boot enabled, which provides a logical locking mechanism
     to restrict the use of open samples.
 8.  The Silicon Creator may issue a Certificate Revocation List (CRL) to the
@@ -402,7 +402,7 @@ more details.
 The public portion of the Creator Identity is tested against the Creator
 Certificate. The result is reported to the TESTER via SPI.
 
-### Self-Generated Process {#self_generated_process}
+### Self-Generated Process
 
 This section describes the personalization self-generate mode in detail. In this
 mode, The device generates its own device secrets and the provisioning appliance
@@ -523,7 +523,7 @@ more details.
 The public portion of the Creator Identity is tested against the Creator
 Certificate. The result is reported to the TESTER via SPI.
 
-## Owner Personalization {#owner_personalization}
+## Owner Personalization
 
 OpenTitan provides a mechanism to enable provisioning of Silicon Owner secrets
 and endorsement certificates in manufacturing and post-manufacturing stages.

doc/security/specs/device_provisioning/README.md

@@ -93,7 +93,7 @@ the
 [UICC EID Specification](https://www.gsma.com/newsroom/wp-content/uploads/SGP.02-v4.0.pdf)
 as an example.
 
-## Creator Root Key (`CreatorRootKey`) {#creator-root-key}
+## Creator Root Key (`CreatorRootKey`)
 
 The following sequence describes the creation of the `CreatorRootKey`. All
 inputs into the key manager can be locked down during ROM execution.
@@ -247,7 +247,7 @@ The `CreatorIdentitySeed` and the private portion of the Creator Identity shall
 be cleared before the ROM Extension hands over execution to the Silicon Owner
 first boot stage.
 
-## OwnerIntermediateKey {#owner-intermediate-key}
+## OwnerIntermediateKey
 
 The `OwnerIntermediateKey` is used as a root component of the Silicon Owner key
 hierarchy. It is used to establish a cryptographic link to the root secrets
@@ -338,7 +338,7 @@ Visibility: Hidden from software.
 The `OwnerIdentitySeed` and the private portion of the Owner Identity shall be
 cleared before the bootloader (BL0) hands over execution to the kernel.
 
-## Owner Root Key and Versioned Keys {#owner-root-key}
+## Owner Root Key and Versioned Keys
 
 The key manager supports the generation of versioned keys with lineage to the
 `OwnerRootKey` for software consumption and sideload operations.
@@ -439,7 +439,7 @@ charge of enforcing isolation.
   </tr>
 </table>
 
-### Software Binding {#software-binding}
+### Software Binding
 
 Software binding is used to ensure that the key derivation scheme is only
 reproducible for a trusted software configuration. This is achieved by having
@@ -453,7 +453,7 @@ implement binding with the application layer exclusively in software.
 
 Each key manager binding stage shall provide at least 128b of data.
 
-### Key Versioning {#key-versioning}
+### Key Versioning
 
 Key versioning is the mechanism by which software implements key rotation
 triggered by security updates. Since there may be more than one updateable code
@@ -514,15 +514,15 @@ hardening.
 
 ## Recommendations for Programming Model Abstraction
 
-### High Level Key Manager States {#high-level-key-manager-states}
+### High Level Key Manager States
 
 The hardware may opt to implement a software interface with higher level one-way
 step functions to advance the internal state of the key manager. The following
 are the minimum set of steps required:
 
-1   [CreatorRootKey](#creator-root-key)
-2   [OwnerIntermediateKey](#owner-intermediate-key)
-3   [OwnerRootKey](#owner-root-key)
+1   [CreatorRootKey](#creator-root-key-creatorrootkey)
+2   [OwnerIntermediateKey](#ownerintermediatekey)
+3   [OwnerRootKey](#owner-root-key-and-versioned-keys)
 
 <table>
   <tr>

doc/security/specs/identities_and_root_keys/README.md

@@ -54,7 +54,7 @@ They send it back in an `UNLOCKED_OWNERSHIP` state.
 (This unlocking step is vital, although the Silicon Creator can endorse a new owner, they cannot unlock ownership for a device that is in a `LOCKED_OWNERSHIP` state.)
 The Silicon Creator can later endorse the ownership transfer payload of whoever buys the device, without further involvement from the previous owner.
 
-## Owner Keys {#owner-keys}
+## Owner Keys
 
 The following keys are provisioned as part of this flow.
 
@@ -104,7 +104,7 @@ Boot stages:
     *   `BL0`: Bootloader. Signed by the Silicon Owner.
     *   `KERNEL`: Signed by the Silicon Owner.
 
-## Key Provisioning {#key-provisioning}
+## Key Provisioning
 
 As part of the Ownership Transfer flow, the Silicon Owner keys are endorsed
 either by the Silicon Creator or by the Current Owner of the device. This is
@@ -290,7 +290,7 @@ However, there must be at least one mechanism available to perform ownership
 transfer at manufacturing time using an implementation compatible with ATE[^2]
 infrastructure.
 
-### Unlock Ownership {#unlock-ownership}
+### Unlock Ownership
 
 This flow implements transition from `LOCKED_OWNERSHIP` to `UNLOCKED_OWNERSHIP` states. It
 is used by the Silicon Owner to relinquish ownership of the device and enable
@@ -374,7 +374,7 @@ before propagating the result to the Host. The Host propagates the unlock result
 to the Device Registry. The Device Registry may opt to remove the device from
 its allow-list.
 
-### Ownership Transfer {#ownership-transfer-device}
+### Ownership Transfer
 
 An ownership transfer command sent by a host to OpenTitan, is serviced by the
 ROM extension (`ROM_EXT`) allowing the Silicon Owner to take ownership of the
@@ -525,7 +525,7 @@ Detailed steps:
     shared memory region and triggers a reset to perform ownership transfer on
     the next boot cycle.
 7.  The `ROM_EXT` executes the ownership transfer flow described in the
-    [Ownership Transfer](#ownership-transfer-device) section with the following
+    [Ownership Transfer](#ownership-transfer) section with the following
     differences:
     1.  Flash erase and flash image stages are not executed.
     2.  The activate owner stage may be delayed and executed later depending on
@@ -545,7 +545,7 @@ implemented by storing the Silicon Owner BL0 verification keys in the `ROM_EXT`.
 The `ROM_EXT` is thus not required to implement ownership transfer in this
 configuration.
 
-## Flash Layout {#flash-layout}
+## Flash Layout
 
 To simplify the implementation, the flash layout implements fixed offset and
 size allocations for the `ROM_EXT` and the certificate storage regions. This

doc/security/specs/ownership_transfer/README.md

@@ -15,7 +15,7 @@ The diagram below summarizes the specific steps involved in the secure boot proc
 
 <img src="secure_boot_flow.svg" style="width: 800px;">
 
-## ROM {#rom}
+## ROM
 
 The first stage of secure boot is called "ROM".
 ROM is a region of read-only memory that cannot be updated at all after an OpenTitan device is manufactured.
@@ -40,7 +40,7 @@ On boot, the ROM code does the following:
 5. Check the signature from the manifest against the digest and the selected Silicon Creator public key.
     * Unlock flash execution, configure ePMP so that the `ROM_EXT` region is executable, and jump to the start of `ROM_EXT`.
 
-## `ROM_EXT` {#rom-ext}
+## `ROM_EXT`
 
 The `ROM_EXT` ("ROM extension") stage is another region of read-only memory that is controlled by the Silicon Creator.
 However, unlike the ROM, it *can* be updated after the device is manufactured, as long as the new version is signed by the Silicon Creator.
@@ -69,7 +69,7 @@ Once the code has jumped into the Silicon Owner code at BL0, secure boot in its
 The Silicon Owner may choose to extend the secure boot process with multiple boot stages of their own; this will differ between device owners, while the stages described here are guaranteed by the Silicon Creator and will be shared by all OpenTitan implementations.
 If any signature verification in the above process fails, or there is any kind of unexpected error, the device will fail to boot.
 
-# Silicon Creator Keys {#silicon-creator-keys}
+# Silicon Creator Keys
 
 The Silicon Creator has multiple public keys.
 This redundancy partially protects against the scenario in which one of the keys is compromised; any OpenTitan devices produced after the key is known to be compromised can mark the compromised key invalid, without requiring a full new ROM implementation.
@@ -129,7 +129,7 @@ The Silicon Owner can change during the lifetime of the device, but the Silicon
 *   `BL0`: Bootloader. Signed by the Silicon Owner.
 *   `Kernel`: Post-bootloader code. Signed by the Silicon Owner.
 
-# Boot Policy {#boot-policy}
+# Boot Policy
 
 In order to provide a flexible boot mechanism the Boot Info page will store a
 structure called the Boot Policy. The boot policy dictates the boot flow,
@@ -138,7 +138,7 @@ the ROM code to decide when to mark a `ROM_EXT` good or bad. The boot policy
 also contains directions to `ROM_EXT` about which slot it loads silicon owner
 code from. TODO(gdk): Expand on policy.
 
-# Memory Layout {#memory-layout}
+# Memory Layout
 
 <img src="flash_layout.svg" style="width: 800px;">
 
@@ -151,7 +151,7 @@ beginning of each physical flash bank. It is expected that a Silicon Owner might
 arbitrarily reserve space at the end of each flash bank to use as additional
 storage.
 
-# Boot Services {#boot-services}
+# Boot Services
 
 Boot Services refers to the functionality stored inside of `ROM`/`ROM_EXT` that
 can be controlled via specific messages passed between from Silicon Owner code

doc/security/specs/secure_boot/README.md

@@ -15,7 +15,7 @@ void edn_init(unsigned int enable) {
 }
 ```
 
-## Module enable and disable {#enable-disable}
+## Module enable and disable
 
 EDN may only be enabled if CSRNG is enabled.
 Once disabled, EDN may only be re-enabled after CSRNG has been disabled and re-enabled.

hw/ip/edn/doc/programmers_guide.md

@@ -122,7 +122,7 @@ CSRNG application commands will be sent immediately.
 Once these commands have completed, a status bit will be set.
 At this point, firmware can later come and reconfigure the EDN block for a different mode of operation.
 
-The recommended write sequence for the entire entropy system is one configuration write to ENTROPY_SRC, then CSRNG, and finally to EDN (also see [Module enable and disable](#enable-disable)).
+The recommended write sequence for the entire entropy system is one configuration write to ENTROPY_SRC, then CSRNG, and finally to EDN (also see [Module enable and disable](./programmers_guide.md#module-enable-and-disable)).
 
 ### Interrupts