The working secerio is that I'm testing OP-TEE on a Hikey board(Cortex-A53, armv8), and they use arm-trusted-firmware(see https://github.com/linaro-swg/arm-trusted-firmware) to be the monitor running in EL3.
I'm trying to access some resources in EL1 by specifying an virtual memory that would work in EL1, for example, if the address of sys_call_table in EL1 is whatever_the_addr, then I try to access the addr in EL3 directly by using
memcpy(dest, whatever_the_addr, size); //where dest is an array allocated in EL3.
I do the access in the beginning `smc_handler` working in EL3, so that when the EL1 linux kernel launches an SMC instruction(which would be routed to EL3), I do the access.
However, the system just hung up and I couldn't figure out why. I have put the value of TTBR0_EL1 into TTBR0_EL3(which means that their page base registers are the same now), why would the access still fail? Would the SMC call cause some context changes? But I didn't find relevant information in the ARM SMC calling conventions(see http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028a/index.html).
If I'm not supposed to access it directly, how could I access these memories exactly? Could anyone please give me some clues? I'd appreciate it very much if anyone could help me with it.
BTW, when I decide to access some memory in EL1, the EL1 normal world system has already been running.
Thanks a lot.Tgn
The EL0/EL1 virtual address is made up of region at the bottom and top of the address range. This is diagram we sometimes use to illustrate this:
TTBR0_EL1 points at the table used to translate the bottom range (VAs 0x0 to 0x0000,FFFF,FFFF,FFFF).
TTBR1_EL1 points at the table used to translate the top range (VAs 0xFFFF,0000,0000,0000 to 0xFFFF,FFFF,FFFF,FFFF)
Both of these registers are common to Secure and Non-secure states. This means that it is up to the EL3 software to context switch their values when transitioning from state to the other.
Typically (although this is not mandated) kernel space uses TTBR1, and user/application space uses TTBR0. In other words, the Linux kernel uses the high address range and the apps would use the lower address range.
It really depends on what you are trying to achieve. Typically when sharing memory between Secure and Non-secure states, both software stacks know the physical address of the shared memory. And then map it into their own virtual address spaces. That is, the shared memory appears at different virtual addresses in the two worlds.
Thanks a lot for your detailed answer. I had intented to access non-secure EL1 memory(such as sys_call_table or some code segment) in EL3 or secure-EL1 level. It seems not possible not now, since the context switch is completed in the EL3 secure monitor, but the monitor itself could not translate memory like Non-secure EL1 does, and secure-EL1 does not contain code that can get/switch the cpu context.
BTW, Can I ask a question which seems irelevant here, that is, can I trap some access to critical registers like SCTLR_EL1 and TTBR0_EL1 from EL1 to EL3? I read the armv8 reference and find that I can trap it from EL1 to EL2, but no description on how to trap it to EL3.
Thanks again for your help.