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
I'm not an expert on OP-TEE, so will stick to the architectural side.
The translation tables are bit patterns in memory, pointed at by the relevant TTBR. However, how you interpret those tables is determined by set of configurations stored in other registers. For example:
Just copying TTBR0_EL1 to TTBR0_EL3 is unlikely to work, as unless all these other settings are the same, the tables will be interpreted differently. And hence give different results.
Then there is the question of which TTBR0_EL1 value you copied. In ARMv8-A, when EL3 uses AArch64, there is only a single copy of TTBR0_EL1 used by both S.EL1 and NS.EL1. It's up to the EL3 software to perform the context switch. If you've just taken the SMC from Non-secure state, it's probably the NS.EL1 value of TTBR0_EL1 you copied. Is that what you wanted?
There is also the issue of the TLBs, which cache recently used translations. Unless you invalidated the TLBs after writing TTBR0_EL3, it's possible it's still using an old cached translation. Assuming you put the value of TTBR0_EL3 back afterwards, there is also the risk that when you restart execution you'll have corrupt TLB entries.
Hi, Martin Weidmann,
Thanks for your answer. Yes, I want the EL3 monitor to get the value of NS.EL1 value of TTBR0_EL1, so that I would be able to access some memory values of normal world according to its way to translate memory. And do you mean that both secure world and normal world use TTBR0_EL1? But I remember that S.EL1 uses TTBR1_EL1, which is different from the NS.EL1 who uses TTBR0_EL1.
I have invalidate the TLBs already, and cleared the I cache and D cache, and I change the TTBR0_EL3 right after I invalidate them. So I guess it is because I haven't changed the other settings you mentioned above.
If not possible to access the memory as normal world does, can I do this in secure world? Secure world is also at EL1, although they may use different TTBR registers
Thanks
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.