请问如果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, ethanzhang
谢谢你的回复,确实是通过SharedMemory来访问的,但是这样secure world就完全不知道normal world里面发生的事件,这个smc不知道是不是正常的请求还是恶意的。
我是看有几篇论文都说了检查EL1里面某些关键内存的值,所以我想尝试一下看看能不能访问到EL1里面linux内核的比如sys_call_table的内容,但是一访问就hung了。我是把TTBR0_EL1的值赋值给了TTBR0_EL3, 然后想让EL3在smc_handler里面去按照normal world的方式去访问(因为我想着EL3是最高的特权级,应该是可以访问所有内存的).
Hi yzh07137,
在设计Trusted OS时会考虑到你提到的问题,一般是把monitor做的比较简单,主要做switch world。但是在设计Trusted OS和Trusted Application时一般都认为所有Normal world的request是Non-trusted,都会check Security。所以安全检查机制一般都放到Trusted OS或者Trusted Application中实现。
Hi, ehanzhang,
能请教一下Trusted OS有什么方法可以访问normal world的一些内存内容吗,因为Trusted OS似乎使用的是ttbr1_el0,和normal world也不是一套页表,还是需要转换页表才能访问。
如果单纯根据传递过去的参数判断的话又起不到安全的作用,因为参数主要还是当作请求的TA的类型,secure world根据参数是无法判断normal world目前的状态,如果被攻击了,直接冒充正常用户去发送这个请求,Trusted OS是无法知道到底合不合法的。
这个要根据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,感觉大部分还是做成的是一个安全隔离的环境