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.

Hi Vasily,

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.

Issue has been addressed with an update to the syncing scripts.

Hi Pete, thanks for your message.

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.

Hi Simon,

Patch available for review at
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2303

Patch available for review at
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2302

My patch was a duplicate of https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2198, so I dropped #2205.

Fix pushed to https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2205

code review : https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2197

Hi David,

Hi there!

Hi David,

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:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads

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?

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!

In T464#5627, @soby-mathew wrote:

Hi vivina,

Hi @soby-mathew !

Hi vivina,
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:
https://forums.juniper.net/t5/Security/What-s-the-Difference-between-Secure-Boot-and-Measured-Boot/ba-p/281251

Thanks Sandrine!

Hi Viviane,