I will close this ticket, as there was no activity since 2022 and I am assuming Chris' answer covered it.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mon, Oct 28
Mar 15 2021
Aug 24 2020
Jul 30 2020
@ManishVB-Arm has posted a patch to address your issue, see https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5119
Would you mind taking a look and letting us know whether it fixes the issue for you?
May 11 2020
May 5 2020
May 4 2020
Apr 21 2020
@soby-mathew: That was the intended meaning. Reworded, thanks.
Apr 16 2020
@raghuncstate Thanks!
Apr 15 2020
Mar 31 2020
OK. Regarding naming suggestions, I like func_noabi/endfunc_noabi the most. The reason why I am discounting asmfunc/endasmfunc is because a function implemented in assembly language might still respect the ABI.
I suggest we start with func_noabi/endfunc_noabi and continue the discussion on the patch on Gerrit. Unfortunately, this ticketing system does not have the same visibility as Gerrit or the mailing list and not everyone subscribe to these.
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
This makes sense to me. Would you mind preparing a patch that removes the func macro on el3_exit and post it on review.trustedfirmware.org ?
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.
@danh-arm Good point, done.
Dec 20 2019
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
I've subscribed both of you to this ticket because git blame shows you as contributors for this platform port. Sorry if you're not the right people to notify about this and feel free to bounce that back to whoever would be appropriate!
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2302 has been merged so I am closing this task.
Fixed by the following patch: https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/2834
Credit to @MarekBykowski .
Nov 8 2019
Oct 21 2019
Hi Simon,
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 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
Sorry, I completely missed your point at first!
Sep 3 2019
Aug 7 2019
Hi Viviane,
Jun 19 2019
Jun 14 2019
May 7 2019
May 3 2019
This might be related to https://developer.trustedfirmware.org/T127
Apr 17 2019
Apr 15 2019
Apr 12 2019
Apr 11 2019
Apr 8 2019
Apr 3 2019
Apr 2 2019
Mar 4 2019
Feb 20 2019
On the other hand, this might just hide issues. This ticket needs more thoughts.
Dec 13 2018
The MPIDR_CPU/CLUSTER_ID macros have been removed by this patch.