Apr 5 2021
I solved this issue by myself.
The assert state works normally.
Apr 1 2021
Aug 24 2020
Mar 27 2020
Mar 24 2020
Sorry if it wasn't clear in my original answer, the SAVE_KEYS=1 option (and friends) must be passed on the command line when you build the firmware, not the cert_create tool itself. The tool has no built-in knowledge of which keys it should use, instead it is told so when it is invoked.
Mar 19 2020
Hi @sandrine-bailleux-arm, where do the PEM files go? Because I still can't find them.
Thanks a lot @sandrine-bailleux-arm for the input. I will try it now.
Mar 18 2020
By default, the cert_create tool creates temporary keys that it keeps in RAM just to sign the certificates. These keys are not stored in files on the disk and are thus discarded after the tool exits.
If you want to save them, please have a look at the SAVE_KEYS build option. In your case, adding SAVE_KEYS=1 NON_TRUSTED_WORLD_KEY=ntw.key BL31_KEY=bl31.key to your command line should do what you want. You'll get the private keys in PEM format I believe, from which you can generate the associated public keys using the openssl tool (or equivalent) if needed.
Mar 17 2020
Mar 3 2020
Mar 2 2020
Feb 27 2020
Feb 26 2020
Feb 25 2020
Feb 24 2020
Feb 19 2020
Feb 17 2020
Feb 15 2020
Jan 15 2020
Jan 7 2020
Could you please send this query to the TF-A mailing list ?
Dec 24 2019
I'm not too much versed into RAS error handling, so please take my explanation below with care.
I suggest you send the question to the TF-A ML to get more sensible insights.
Dec 23 2019
Dec 20 2019
I'll post this question to mailing list as suggested.
I am not aware of any specific reason for LOG_LEVEL values being multiple of 10's. I guess at the time we thought we should leave room in between values, just in case we'd like to add more intermediate values in the future. In the end, I think it proved unnecessary but it stayed like that. I don't foresee the need for more log levels today so IMHO it would be OK to change their values to 1,2,3 and so on, as you suggested.
Dec 19 2019
If we set the LOG macros to 1,2,3 so on, we can avoid the mod and division operation when printing the msg to console.
Oct 2 2019
Oct 1 2019
Sep 18 2019
Could you please elaborate on your issue? How are you trying to configure your email address in Gerrit? Are you doing it from the user settings page? Do you have no email address registered on Gerrit at all or are you trying to add a secondary one? When is the error 422 showing?
Sep 17 2019
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.