138402e7ff
coreboot's method of creating IFWI is to modify an existing IFWI images by deleting the IBB, replacing the IBBL with the bootblock and everything else is put in the OBB. This poses a problem when using Intel's FIT or technologies such as Boot Guard. The main problem is that the IBB is never verified by the CSE or copied from SRAM to CAR, so the CSE cannot complete BUP and stays in recovery mode. The vast majority of the stages in Apollolake's Secure Boot flow is not met using this method (Intel document number 597827 summarizes these steps). This patch series is based on the principles of a patch from Brenton Dong (CB:17064) creates an IBBL, IBB and OBB binaries with the correct functions to complete the Secure Boot flow. This is to copy the IBB from SRAM using the CSE's Ring Buffer Protocol. These binaries can then be used by FIT or coreboot's existing method of hacking IFWI together (IFWI_STITCH) via IFWITOOL. If it is the latter and Boot Guard is enabled, the hashes for IFWI and "ibb+obb" must be recreated. Whilst this option doesn't form a complete image, the components it builds will work as Intel intended them to once stitched correctly into an IFWI image. Signed-off-by: Sean Rhodes <sean@starlabs.systems> Change-Id: I0deebf04f22f3017ee0c13bf1ca7f6dcc0d458b5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/65680 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> |
||
|---|---|---|
| .. | ||
| amd | ||
| cavium | ||
| example/min86 | ||
| ibm/power9 | ||
| intel | ||
| mediatek | ||
| nvidia | ||
| qualcomm | ||
| rockchip | ||
| samsung | ||
| sifive | ||
| ti | ||
| ucb/riscv | ||
| xilinx | ||