mirror of https://github.com/wolfSSL/wolfBoot.git
F-9759: document that QE/FMan microcode is not authenticated
The P1021 QE and T10xx QE/FMan microcode blobs are validated only for structural integrity (header magic, version, size bounds) before they are activated; no cryptographic authentication is applied. State that in Targets.md for both targets, with the deployment-model reasoning: the P1021 microcode region sits inside the update partition, and the T10xx regions require local board flash write access, which also allows replacing the wolfBoot image itself. Same residual claim as F-8000 and F-9761 (T10xx QE and FMan paths); the bounds fixes for all three are already in master (pull/868/head000c05c7,91c020a2). Product decision: no microcode authentication feature.
parent
0a6a5fe360
commit
431b01560d
|
|
@ -5736,6 +5736,14 @@ A first stage loader is required to load the wolfBoot image into DDR for executi
|
|||
| fsl_qe_ucode_1021_10_A.bin | 0x01F00000 |
|
||||
| swap block | 0x02200000 |
|
||||
|
||||
The QE microcode programmed at `0x01F00000` is validated only for
|
||||
structural integrity (header magic, version, and size bounds) before it
|
||||
is activated; it is not cryptographically authenticated. This is out of
|
||||
scope for the example configuration: the microcode region sits inside
|
||||
the update partition, so replacing it requires the same flash write
|
||||
access that would let an attacker replace the update image itself,
|
||||
which wolfBoot's image authentication already protects against.
|
||||
|
||||
### Building wolfBoot for NXP P1021 PPC
|
||||
|
||||
By default wolfBoot will use `powerpc-linux-gnu-` cross-compiler prefix. These tools can be installed with the Debian package `gcc-powerpc-linux-gnu` (`sudo apt install gcc-powerpc-linux-gnu`).
|
||||
|
|
@ -5888,6 +5896,13 @@ Note: On T1040, FMAN and QE firmware share the same 128KB NOR erase sector
|
|||
(0xEFF00000-0xEFF1FFFF). They must be programmed together in a single
|
||||
erase/write operation.
|
||||
|
||||
The QE and FMan microcode in these NOR regions is validated only for
|
||||
structural integrity (header magic, version, and size bounds) before it
|
||||
is activated; it is not cryptographically authenticated. This is out of
|
||||
scope for the example configurations: programming these regions requires
|
||||
local write access to the board's flash, which also allows replacing the
|
||||
wolfBoot image itself - a threat the signed image flow already covers.
|
||||
|
||||
### Design
|
||||
|
||||
Both T1024 and T1040 use a two-stage boot. Stage1 runs XIP from NOR flash,
|
||||
|
|
|
|||
Loading…
Reference in New Issue