请问如果EL1里面运行的内核调用了一个SMC指令(通过SMC去请求secure world的服务),然后这个调用被运行在EL3的ARM-Trusted-Firmware(EL3运行的相当于monitor)接收到了,这个时候EL3能否按照EL1的地址映射方式去访问EL1里面的虚拟内存?(在访问的时候还没有切换到secure os的context)
比如,EL1里面运行的是linux内核,linux内核空间的虚拟地址为addr1(比如sys_call_table),然后我试图在EL3里面直接通过
memcpy(dest, addr1_of_sys_call_table, size);
这种方式来访问,但是导致系统卡住了,也没有提示访问错误之类的。
我是在smc_handler一开始就访问的,所以应该不会存在什么context破坏的问题(TTBR0_EL1, TTBR0_EL3我都没有动过),除非是smc调用本身会造成一些context的转换,又或者是因为EL3级别使用的是TTBR0_EL3而不是TTBR0_EL1? 如果是这样的话,可以强行暂时把TTBR0_EL1的值赋给TTBR0_EL3然后去直接访问addr1_of_sys_call_table吗?
如果不可以的话,那请问有什么办法在EL3(monitor)级别或者secure-EL1(secure os)级别访问到EL1(normal world)的一些资源呢?
我对于这块还只能算是初学者,提前谢谢大家!
Hi yzh07137,
这个要根据Trusted OS的实现有关,ShareMemory是可以被Rich OS和Trusted OS访问的,例如在OP-TEE初始化中会根据配置建立页表,ShareMemory的Physical Address和Size都是保存在全局变量,运行在Rich OS下的Trustzone Driver通过fastcall向Trusted OS发送请求获取ShareMemory信息,OPP-TEE design doc中介绍了ShareMemory的用途,你可以看下加载TA 的Source Code里面有对TA signed ELF进行校验,希望对你理解ShareMemory 有用.
谢谢,抱歉之前忘了回。现在看来好像并不能在TEE里面主动去访问Normal world,感觉大部分还是做成的是一个安全隔离的环境