Wed, Nov 20
Tue, Nov 19
Mon, Nov 18
Review request is here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2512
Looks like it fixed itself, I was able to confirm my email.
Sun, Nov 17
Sorry guys, your gerrit infrastructure is broken. I can't register my email at review.trustedfirmware.org it complains "Error 422 (Unprocessable Entity): invalid token" when I'm trying to confirm my email.
Fri, Nov 8
Tue, Nov 5
Issue has been addressed with an update to the syncing scripts.
Sat, Nov 2
Hi Pete, thanks for your message.
Thu, Oct 24
Oct 21 2019
I'm using gcc 9.2.0 and GNU binutils 2.32 for AArch64, from Void Linux's cross-aarch64-linux-gnu-0.32_1 package.
Oct 20 2019
Patch available for review at
Patch available for review at
Oct 9 2019
My patch was a duplicate of https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2198, so I dropped #2205.
Oct 8 2019
Sep 17 2019
Sep 11 2019
I don't know what options you tried to build with, but I managed to build with the ROMLIB feature for the FVP platform. I will post everything I did here, hoping it will be of some use to you.
I used the following command to build:
MBEDTLS_DIR=<path_to_mbedtls> make ARM_ROTPK_LOCATION=devel_rsa CROSS_COMPILE=<path_to_cross_compiler(aarch64)> GENERATE_COT=1 PLAT=fvp ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem TRUSTED_BOARD_BOOT=1 USE_ROMLIB=1 DEBUG=1 fiptool all
The cross-compiler I used is GCC 8.3 for AArch64 ELF bare-metal target. You can get it from here:
Sep 10 2019
So, just to be clear: Imagine a scenario with two devices - one I made (I know the keys and code on BL1) and another one that some malicious user cloned (he signed with his own keys). My device will have a Root of Trust in BL1 based on my hardware and the keys I own. The second device also has a BL1 but that image was signed by someone I don't trust. In the end, both devices will boot up successfully because they are based on each individual Chain of Trust but there's no way a third party (i.e. remote attestation server) can know the difference between the malicious device and my device solely relying on Verified Boot, right?
Sep 9 2019
Verified boot in itself already proves the boot integrity of all firmware images from BL1 up to BL33.
BL1 is the root of trust and cannot be tampered with, as it is hardware-protected. All other BL image are signed and their signature is verified before they get executed: BL1 verifies the signature of BL2, and BL2 does the same for all subsequent BL3x images. If one of the signatures is invalid then TF-A refuses to execute the corresponding image. This is treated as a fatal error that the firmware cannot recover from and the platform will typically panic in this case.
Sorry, I completely missed your point at first!
Sep 6 2019
Hi @soby-mathew !
Sep 5 2019
Are you thinking something similar to measured boot ?
The TF-A implements what is called verified boot. Found a good description for difference between verified and measured boot here:
Sep 3 2019
Aug 13 2019
Aug 7 2019