Yes within the TF A ecosystem there exist artifacts such as hashes and objects which play a crucial role in facilitating attestation subsequent to a successful boot process.
Snow Services in O'Fallon IL

I'm glad to see that CMake is addressing this common challenge for developers. Thank you for your interest in getting over it and for your ongoing efforts to simplify the construction process!

It seems like a valid point regarding the use of dmb st in sprt_queue.c. Your analysis on the necessity of memory barriers in single CPU scenarios versus multi CPU/Thread scenarios adds depth to the discussion.
Professional Plumbing Services in Atlanta GA

To overcome this problem, it is necessary to determine the cause of the lack of EOI processing for the RAS interrupt and correct the error in the corresponding software or hardware. This often requires thorough examination and analysis of the source code, interrupt handlers and related systems. aa route planner

I solved this issue by myself.
The assert state works normally.

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.

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.

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.

HI Rickdic,
Could you please send this query to the TF-A mailing list ?

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.

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.

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.

In T498#6134, @semihalf-biernacki-radoslaw wrote:

Hi Haojian,

I have the same problem.
Can you please share the solution you got from maintainer?

Hi Haojian,

Hi Sandrine,

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?

Hi David,

Hi there!

Hi David,

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,

Reopening so it can be answered

It’s better to create a task from scratch than edit the example task. Added back in TF-A project so it is shown on the project workbook with your question.

Thanks guys! The dmbish() is not a huge deal. Just get a little nervous when i see barriers and don't completely understand why it is there. :)

Ah, You are right. Having taken a look at it again, yes, the SP-> SPM communication is register based and this spm_response_add() is invoked by SPM to push to a buffer within EL3 (its not a shared buffer between different ELs). I suspect the shared buffer primitives were written with shared buffer scenario in mind and the current prototype implementation does not optimize it for the case when the buffer is within EL3.

Thanks Paul, Soby.
spm_response_*() currently cannot invoked by any secure partition since the responses[] array is in EL3 space. Is this not the case ? or is it the expectation that the responses array will be mapped to secure EL0 some time in the future? I don't see how a secure partition can invoke spm_response_* other than through an SMC, in which case we are already in EL3 context and dont require the dmbish(), as Paul pointed. I understand your argument for sprt_queue_*, since they are invoked by EL3 and the secure partition.

Who is the lockless reader for spm_response_add() and spm_response_get()?

Apologies for the delay. I've had a look into the spm_buffers.c file and I understand your query is around the dmbish() that's performed shortly before releasing the lock in both spm_response_add() and spm_response_get().

anything ?

Thanks. Missed the lockless reader of the queue. Who is the lockless reader for spm_response_add() and spm_response_get()?

A secure partition may be reading from the queue from CPU1 at the same time as CPU0 pushes a new request. If this happens, it is needed that the stores are seen in the same order by all observers of the system.