[SeaFood]

Hello,

I a newbie in embedded programming. Currently I am developing an embedded tool
running on ARM Cortex-A9. I meet an security issue when trying to use ARM Generic Interrupt Controller (GIC).

Following is the detail describing for my issue:
A. My tool MUST running in non-secure mode. It has to catch interrupt ID 117 (only).
But
B. It seems that (as I investigated) a software running in non-secure mode could not access to secure registers.

Could you please confirm my understanding:
1. Is item B above right?
2. If B is wrong, could you please teach me how to do it. (access to secure registers from a non-secure software).

PS: I've just entered embedded world for 8 months. I think this issue is a little bit hard for me . Please help me.
Thank you in advance.

[ttfn]

Your understanding is correct. Code running the Normal world (non-secure) cannot access secure registers.

All interrupts default to be being "secure" - that is only handable by the Normal world. Code running in the Secure world must configure interrupt IDs as non-secure as required.

[SeaFood]

Thank you very much for answering me.

I heard that SMC instruction is a way for communicating between secure and non-secure world.
Do you have any information about this? Now, i am investigating but it seems ambiguous.

[isogen74]

The "SMC" instruction just causes the processor to trap from a non-secure privileged mode (or a secure privileged mode) into the Monitor mode at the "SVC" vector table entry in the monitor mode vector table. What happens next is entirely determined by the monitor mode software on the platform.

As you already seem to be in non-secure some code must have bootstrapped the system and switched it to non-secure, so I'd ask the provider of your secure world bootstrap or secure OS (if you have one).

[SeaFood]

Thanks for your information.
Now I understand that I can not do anything on GIC except ask the Secure team to change the ROM code setting (for secure).
Is it right?

[isogen74]

Yes, most likely )

They may have some "API" the non-secure world can use to access secure functionality in a was which doesn't kill the whole point of the secure world (like a system call in a typical OS, you can have "function calls" in to the secure world in principle), but it is entirely going to depend on the secure world software implementation.

HTH, Iso