请问如果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, ehanzhang,
能请教一下Trusted OS有什么方法可以访问normal world的一些内存内容吗，因为Trusted OS似乎使用的是ttbr1_el0，和normal world也不是一套页表，还是需要转换页表才能访问。
如果单纯根据传递过去的参数判断的话又起不到安全的作用，因为参数主要还是当作请求的TA的类型，secure world根据参数是无法判断normal world目前的状态，如果被攻击了，直接冒充正常用户去发送这个请求，Trusted OS是无法知道到底合不合法的。
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，感觉大部分还是做成的是一个安全隔离的环境