From 1f4659be619eb5da98d855a2a9b8e9a996ce7456 Mon Sep 17 00:00:00 2001 From: Masaki Iwai Date: Sun, 4 Aug 2024 13:49:33 +0900 Subject: [PATCH] fix links --- wolfBoot/src/appendix01.md | 2 +- wolfBoot/src/appendix02.md | 2 +- wolfBoot/src/appendix10.md | 18 +++++++++--------- wolfBoot/src/appendix11.md | 4 ++-- wolfBoot/src/appendix13.md | 2 +- wolfBoot/src/chapter02.md | 2 +- wolfBoot/src/chapter03.md | 34 +++++++++++++++++----------------- wolfBoot/src/chapter06.md | 4 ++-- wolfBoot/src/chapter07.md | 4 ++-- 9 files changed, 36 insertions(+), 36 deletions(-) diff --git a/wolfBoot/src/appendix01.md b/wolfBoot/src/appendix01.md index 9dba4e4a..82d66415 100644 --- a/wolfBoot/src/appendix01.md +++ b/wolfBoot/src/appendix01.md @@ -21,7 +21,7 @@ DISK_LOCK_PASSWORD=hardcoded_password If the ATA disk has no password set, the disk will be locked with the password provided at the first boot. ## Unlocking the Disk with a TPM-Sealed Secret -wolfBoot allows to seal secret safely in the TPM in a way that it can be unsealed only under specific conditions. Please refer to files TPM.md and measured_boot.md for more information. +wolfBoot allows to seal secret safely in the TPM in a way that it can be unsealed only under specific conditions. Please refer to [Appendix M](appendix13.md) and [Appendix G](appendix07.md)for more information. If the options `WOLFBOOT_TPM_SEAL` and `DISK_LOCK` are enabled, wolfBoot will use a TPM sealed secret as the password to unlock the disk. The following options controls the sealing and unsealing of the secret: | Option | Description | diff --git a/wolfBoot/src/appendix02.md b/wolfBoot/src/appendix02.md index 3a8a1b19..ba7f7e95 100644 --- a/wolfBoot/src/appendix02.md +++ b/wolfBoot/src/appendix02.md @@ -30,7 +30,7 @@ the keystore. ## Signing the firmware image for wolfBoot The signing operation using any external HSM is performed through three-steps, -as described in the relevant section in [Signing.md](signing.md). +as described in the relevant section in [Appendix B](appendix02.md). In this section we describe the procedure to sign the firmware image using Azure key vault. diff --git a/wolfBoot/src/appendix10.md b/wolfBoot/src/appendix10.md index 175c682f..682932eb 100644 --- a/wolfBoot/src/appendix10.md +++ b/wolfBoot/src/appendix10.md @@ -3,17 +3,17 @@ Platforms Supported: - Renesas RZ (RZN2L) (RSIP) - - [docs/Targets.md#renesas-rzn2l](/docs/Targets.md#renesas-rzn2l) - - [IDE/Renesas/e2studio/RZN2L/Readme.md](/IDE/Renesas/e2studio/RZN2L/Readme.md) - - [IDE/Renesas/e2studio/RZN2L/Readme_wRSIP.md](/IDE/Renesas/e2studio/RZN2L/Readme_wRSIP.md) + - [chapter03.md#renesas-rzn2l](chapter03.md#renesas-rzn2l) + - IDE/Renesas/e2studio/RZN2L/Readme.md + - IDE/Renesas/e2studio/RZN2L/Readme_wRSIP.md - Renesas RA (RA6M4) (SCE) - - [docs/Targets.md#renesas-ra6m4](/docs/Targets.md#renesas-ra6m4) - - [IDE/Renesas/e2studio/RA6M4/Readme.md](/IDE/Renesas/e2studio/RA6M4/Readme.md) - - [IDE/Renesas/e2studio/RA6M4/Readme_withSCE.md](/IDE/Renesas/e2studio/RA6M4/Readme_withSCE.md) + - [chapter03.md#renesas-ra6m4](chapter03.md#renesas-ra6m4) + - IDE/Renesas/e2studio/RA6M4/Readme.md + - IDE/Renesas/e2studio/RA6M4/Readme_withSCE.md - Renesas RX (RX65N/RX72N) (TSIP) - - [docs/Targets.md#renesas-rx72n](/docs/Targets.md#renesas-rx72n) - - [IDE/Renesas/e2studio/RX72N/Readme.md](/IDE/Renesas/e2studio/RX72N/Readme.md) - - [IDE/Renesas/e2studio/RX72N/Readme_withTSIP.md](/IDE/Renesas/e2studio/RX72N/Readme_withTSIP.md) + - [chapter03.md#renesas-rx72n](chapter03.md#renesas-rx72n) + - IDE/Renesas/e2studio/RX72N/Readme.md + - IDE/Renesas/e2studio/RX72N/Readme_withTSIP.md All of the Renesas examples support using e2Studio. The Renesas RX parts support using wolfBoot Makefile's with the rx-elf-gcc cross-compiler and example .config files. diff --git a/wolfBoot/src/appendix11.md b/wolfBoot/src/appendix11.md index 5ca589a2..488553aa 100644 --- a/wolfBoot/src/appendix11.md +++ b/wolfBoot/src/appendix11.md @@ -61,7 +61,7 @@ The files generate by the keygen tool is the following: - A binary file `keystore.img` that can be used to provision the public keys through an alternative storage - The private key, for each `-g` option provided from command line -For more information about the keystore mechanism, see [keystore.md](@@@need to change here@@@). +For more information about the keystore mechanism, see [Appendix D](appendix04.md). ### Sign tool @@ -283,4 +283,4 @@ tools/bin-assemble/bin-assemble factory.bin 0x0 wolfboot.bin \ ### Signing Firmware with Azure Key Vault -See [docs/azure_keyvault.md](@@@need to change here@@@). +See [Appendix B](appendix02.md). diff --git a/wolfBoot/src/appendix13.md b/wolfBoot/src/appendix13.md index f95d31d9..5de2c4db 100644 --- a/wolfBoot/src/appendix13.md +++ b/wolfBoot/src/appendix13.md @@ -12,7 +12,7 @@ In wolfBoot we support TPM based root of trust, sealing/unsealing, cryptographic | `WOLFBOOT_TPM_KEYSTORE_NV_BASE=0x` | `WOLFBOOT_TPM_KEYSTORE_NV_BASE=0x` | NV index in platform range 0x1400000 - 0x17FFFFF. | | `WOLFBOOT_TPM_KEYSTORE_AUTH=secret` | `WOLFBOOT_TPM_KEYSTORE_AUTH` | Password for NV access | | `MEASURED_BOOT=1` | `WOLFBOOT_MEASURED_BOOT` | Enable measured boot. Extend PCR with wolfBoot hash. | -| `MEASURED_PCR_A=16` | `WOLFBOOT_MEASURED_PCR_A=16` | The PCR index to use. See [docs/measured_boot.md](/docs/measured_boot.md). | +| `MEASURED_PCR_A=16` | `WOLFBOOT_MEASURED_PCR_A=16` | The PCR index to use. See [Appendix G](appendix07.md). | | `WOLFBOOT_TPM_SEAL=1` | `WOLFBOOT_TPM_SEAL` | Enables support for sealing/unsealing based on PCR policy signed externally. | | `WOLFBOOT_TPM_SEAL_NV_BASE=0x01400300` | `WOLFBOOT_TPM_SEAL_NV_BASE` | To override the default sealed blob storage location in the platform hierarchy. | | `WOLFBOOT_TPM_SEAL_AUTH=secret` | `WOLFBOOT_TPM_SEAL_AUTH` | Password for sealing/unsealing secrets, if omitted the PCR policy will be used | diff --git a/wolfBoot/src/chapter02.md b/wolfBoot/src/chapter02.md index aa43261f..5437da2c 100644 --- a/wolfBoot/src/chapter02.md +++ b/wolfBoot/src/chapter02.md @@ -222,7 +222,7 @@ Note: if you are using an external FLASH (e.g. SPI) in combination with a flash ### Using One-time programmable (OTP) flash as keystore By default, keys are directly incorporated in the firmware image. To store the keys in a separate, one-time programmable (OTP) flash memory, use the `FLASH_OTP_KEYSTORE=1` option. -For more information, see [/docs/OTP-keystore.md](@@@need to change here@@@). +For more information, see [Appendix C](appendix03.md). ### Prefer multi-sector flash erase operations diff --git a/wolfBoot/src/chapter03.md b/wolfBoot/src/chapter03.md index cfdd849d..1e8a4455 100644 --- a/wolfBoot/src/chapter03.md +++ b/wolfBoot/src/chapter03.md @@ -168,7 +168,7 @@ non-secure callables (NSC). The example configuration for this scenario is available in `/config/examples/stm32l5-wolfcrypt-tz.config`. -For more information, see [/docs/STM32-TZ.md](@@@need to change here@@@). +For more information, see [Appendix L](appendix12.md). ### Scenario 3: Trustzone Disabled, using DUAL BANK @@ -316,9 +316,9 @@ This option can be enabled with the `WOLFCRYPT_TZ=1` and `WOLFCRYPT_TZ_PKCS11=1` options in your configuration. This enables a PKCS11 accessible from NS domain via non-secure callables (NSC). -The example configuration for this scenario is available in [/config/examples/stm32u5-wolfcrypt-tz.config](/config/examples/stm32u5-wolfcrypt-tz.config). +The example configuration for this scenario is available in `/config/examples/stm32u5-wolfcrypt-tz.config`. -For more information, see [/docs/STM32-TZ.md](/docs/STM32-TZ.md). +For more information, see [Appendix L](appendix12.md). ### Scenario 3: TrustZone Disabled (DUAL BANK mode) @@ -535,9 +535,9 @@ with RSA2048: ### Building STM32C0 -Reference configuration files (see [config/examples/stm32c0.config](/config/examples/stm32c0.config), -[config/examples/stm32c0-rsa2048.config](/config/examples/stm32c0-rsa2048.config) and -[config/examples/stm32c0-lms-8-10-1.config](/config/examples/stm32c0-lms-8-10-1.config)). +Reference configuration files (see `config/examples/stm32c0.config`, +`config/examples/stm32c0-rsa2048.config` and +`config/examples/stm32c0-lms-8-10-1.config`). You can copy one of these to wolfBoot root as `.config`: `cp ./config/examples/stm32c0.config .config`. To build you can use `make`. @@ -868,7 +868,7 @@ through different scenarios. Additionally, wolfBoot can be compiled with `FLASH_OTP_KEYSTORE` option, to store the public key(s) used for firmware authentication into a dedicated, one-time programmable flash area that can be write protected. -For more information, see [/docs/flash-OTP.md](/docs/flash-OTP.md). +For more information, see [Appendix C](appendix03.md). ### Scenario 1: TrustZone enabled, staging non-secure application @@ -880,7 +880,7 @@ SRAM memories into two parts: - the first 256KB are used by wolfboot running in secure mode and the secure application - the remaining available space is used for non-secure application and update partition -The example configuration for this scenario is available in [/config/examples/stm32h5.config](/config/examples/stm32h5.config). +The example configuration for this scenario is available in `/config/examples/stm32h5.config`. #### How to use it @@ -897,7 +897,7 @@ The example configuration for this scenario is available in [/config/examples/st - flash the application image to the non-secure partition: `STM32_Programmer_CLI -c port=swd -d test-app/image_v1_signed.bin 0x08040000` -For a full list of all the option bytes tested with this configuration, refer to [STM32-TZ.md](/docs/STM32-TZ.md). +For a full list of all the option bytes tested with this configuration, refer to [Appendix L](appendix12.md). ### Scenario 2: TrustZone Enabled, wolfCrypt as secure engine for NS applications @@ -908,9 +908,9 @@ This option can be enabled with the `WOLFCRYPT_TZ=1` and `WOLFCRYPT_TZ_PKCS11=1` options in your configuration. This enables a PKCS11 accessible from NS domain via non-secure callables (NSC). -The example configuration for this scenario is available in [/config/examples/stm32h5-tz.config](/config/examples/stm32h5-tz.config). +The example configuration for this scenario is available in `/config/examples/stm32h5-tz.config`. -For more information, see [/docs/STM32-TZ.md](/docs/STM32-TZ.md). +For more information, see [Appendix L](appendix12.md). ### Scenario 3: DUALBANK mode @@ -1366,7 +1366,7 @@ tested with MpLab IDE v. 6.20. The example application can be used to update the firmware over USB. More details about building the example projects can be found in the -[IDE/MPLAB](/IDE/MPLAB) directory in this repository. +`IDE/MPLAB` directory in this repository. ### Uploading the bootloader and the firmware image @@ -1999,7 +1999,7 @@ c ## TI Hercules TMS570LC435 -See [/config/examples/ti-tms570lc435.config](/config/examples/ti-tms570lc435.config) for example configuration. +See `/config/examples/ti-tms570lc435.config` for example configuration. @@ -2166,7 +2166,7 @@ With RX GCC path or or custom cross compiler directly: OR `make RX_GCC_PATH="~/toolchains/gcc_8.3.0.202311_rx_elf"` -TSIP: To enable TSIP use `make PKA=1`. See [docs/Renesas.md](docs/Renesas.md) for details. +TSIP: To enable TSIP use `make PKA=1`. See [Appendix J](appendix10.md) for details. ### Flashing Renesas RX65N @@ -2202,7 +2202,7 @@ Create a new "Renesas Debug" project. Choose the "E2 Lite" emulator and the buil Tested on the RX72N ENVISION KIT (HMI development kit for IoT systems). This includes an onboard E2 Lite emulator. -The Renesas RX72N is supported either natively with "make" or through e2Studio. If using e2Studio see [Readme.md](../IDE/Renesas/e2studio/RX72N/Readme.md). +The Renesas RX72N is supported either natively with "make" or through e2Studio. If using e2Studio see `/IDE/Renesas/e2studio/RX72N/Readme.md`. Default UART Serial on SCI2 at P12-RXD2 P13-TXD2. Use USB on CN8 to attach a Virtual USB COM port. This feaure is enabled with `DEBUG_UART=1`. @@ -2280,7 +2280,7 @@ OR `make RX_GCC_PATH="~/toolchains/gcc_8.3.0.202311_rx_elf"` -TSIP: To enable TSIP use `make PKA=1`. See [docs/Renesas.md](@@@need to change here@@@) for details. +TSIP: To enable TSIP use `make PKA=1`. See [Appendix J](appendix10.md) for details. ### Flashing Renesas RX72N @@ -2747,7 +2747,7 @@ IMAGE=test-app/image.elf SIGN=--ecc384 tools/scripts/x86_fsp/qemu/make_hd.sh ./tools/scripts/x86_fsp/qemu/qemu.sh -t ``` -For more advanced uses of TPM, please check [TPM.md](@@@need to change here@@@) to configure wolfBoot +For more advanced uses of TPM, please check [Appendix M](appendix13.md) to configure wolfBoot according to your secure boot strategy. ### Running on Kontron VX3060-S2 diff --git a/wolfBoot/src/chapter06.md b/wolfBoot/src/chapter06.md index 26afa1b1..85baf871 100644 --- a/wolfBoot/src/chapter06.md +++ b/wolfBoot/src/chapter06.md @@ -440,7 +440,7 @@ The custom fields are identified by a 16-bit tag, and their size is indicated by At runtime, the values stored in the manifest header can be accessed using the `wolfBoot_find_header` function. -The syntax for `--custom-tlv` option is also documented in [docs/Signing.md](@@@need to change here@@@/docs/Signing.md#adding-custom-fields-to-the-manifest-header). +The syntax for `--custom-tlv` option is also documented in [Appendix H](appendix08.md). #### Image header: Example @@ -635,7 +635,7 @@ Consider implementing these three functions based on the provided examples if yo On the remote system hosting the external partition image for the target, a simple protocol can be implemented on top of UART messages to serve flash-access specific calls. -An example uart-flash-server daemon, designed to run on a GNU/Linux host and emulate the external partition with a local file on the filesystem, is available in [tools/uart-flash-server](tools/uart-flash-server). +An example uart-flash-server daemon, designed to run on a GNU/Linux host and emulate the external partition with a local file on the filesystem, is available in `tools/uart-flash-server`. ### External flash update mechanism diff --git a/wolfBoot/src/chapter07.md b/wolfBoot/src/chapter07.md index 0b9de738..0f07e05c 100644 --- a/wolfBoot/src/chapter07.md +++ b/wolfBoot/src/chapter07.md @@ -9,7 +9,7 @@ - Equip the application with the [wolfBoot library](chapter06.md#application-interface-for-interactions-with-the-bootloader) to interact with the bootloader - [Configure and compile](chapter02.md#compiling-wolfboot) a bootable image with a single "make" command - For help signing firmware see [wolfBoot Signing](chapter06.md#signing) - - For enabling measured boot see [wolfBoot measured boot](chapter06.md#measured-boot) + - For enabling measured boot see [wolfBoot measured boot](chapter06.md) ## Examples provided @@ -28,7 +28,7 @@ The factory image can be flashed to the target device. It contains the bootloade The `sign.py` tool transforms a bootable firmware image to comply with the firmware image format required by the bootloader. -For detailed information about the firmware image format, see [Firmware image](chapter06.md#firmware-image) +For detailed information about the firmware image format, see [Firmware image](chapter06.md) For detailed information about the configuration options for the target system, see [Compiling wolfBoot](chapter02.md#compiling-wolfboot)