34. OP-TEE中system call的实现

本文详细介绍了OP-TEE中的系统调用机制,包括如何通过UTEE_SYSCALL宏定义系统调用接口、系统调用表tee_svc_syscall_table的作用及其实现原理。此外还解释了从用户空间到内核空间的切换过程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

   

  

在GP文档中定义了很多接口,而这些接口大部分都是给TEE中的TA调用的,例如实现AES,RSA,SHA,HMAC,PBKDF等等算法在GP中都有统一的接口,该部分在OP-TEE编译的时候会被编译到libutee.a的库文件中,以备OP-TEE的userspace层面使用。TA中可以通过调用这些接口来完成对数据的加解密以及验签等操作。如果板级有hardware cipher的话,调用这些算法接口之后最终会使用底层cipher驱动来完成计算操作。而cipher驱动是处于kernel space层面的,这也就衍生出了OP-TEE的system call的需求。在OP-TEE中userspace的接口一般定义成utee_xxx_xxx的形式,而其对应的system call则为syscall_xxx_xxx。也即是在OP-TEE的userspace层面调用utee_xxx_xxx函数,系统最终会调用syscall_xxx_xxx来实现处理,可参考linux中系统调用的概念。在OP-TEE中一次完整的系统调用过程如下:

  OP-TEE的系统调用的关键点上是通过svc切换到kernel space,通过类似中断的方式结合参数在系统调用数组中找到对应的函数并执行。完成之后切换cortex模式返回到userspace。

1. UTEE_SYSCALL宏

  在定义一个syscall的时候,在userspace层面需要通过UTEE_SYSCALL宏来实现,在OP-TEE中所有的utee_xxx类的接口都使用该宏定义在utee_syscalls_asm.S文件中,该宏使用汇编来实现,内容如下:

  .macro UTEE_SYSCALL name, scn, num_args
	FUNC \name , :

        push    {r5-r7,lr}	//保存r5~r7和lr
        mov     r7, #(\scn)	//将scn的值保存到r7中,scn为syscall的index
/* 检查参数个数,并根据num_args 的值来配置参数个数和参数在sp中的位置 */
	.if \num_args > TEE_SVC_MAX_ARGS
	.error "Too many arguments for syscall"
	.endif
        .if \num_args <= 4
        @ No arguments passed on stack
        mov     r6, #0
        .else
        @ Tell number of arguments passed on the stack
        mov     r6, #(\num_args - 4)
        @ Point just before the push (4 registers) above on the first argument
        add     r5, sp, #(4 * 4)
        .endif
        svc #0	//触发类svc中断
        pop     {r5-r7,pc}	//svc处理完成之后返回继续执行
	END_FUNC \name
        .endm

  该宏相当于实现了utee_xxx的函数,在宏参数中name相当于是utee_xxx,scn是系统调用的index, numargs参数个数,小于或者等于4则表示不需要传递数据给system call。

2. 系统调用表tee_svc_syscall_table

  在kernel space中定义了一个系统调用的数组表tee_svc_syscall_table,该数组中包含了当前OP-TEE中支持的所有系统调用在kernel space的实现,该数组定义在optee_os/core/arch/arm/tee/arch_svc.c文件中。由于该数组较大,在此就不贴出来了。当在userspace中触发了svc之后,最终会调用到tee_svc_handler函数,在该函数中就会使用在userspace传递过来的scn值从tee_svc_syscall_table中获取到syscall的实现。即tee_svc_syscall_table[scn]中的内容即为需要调用的具体函数。

  在tee_svc_handler中会调用tee_svc_do_call来执行tee_svc_syscall_table[scn]中定义的函数。在真正执行tee_svc_syscall_table[scn]之前会保存相关寄存器以便执行完成之后恢复到userspace,而且还需要将Userspace中带入的数据拷贝到kernel space供tee_svc_syscall_table[scn]中的函数使用。

 

151.250174699999DBGC~ ~ ====1609430805.188988-D Panic#1 Part1 <5>[ 39.221003] audit: type=1325 audit(1609430702.167:25): table=filter family=2 entries=14 op=xt_replace pid=3630 subj=system_u:system_r:system_t comm="iptables" <5>[ 52.258603] audit: type=1325 audit(1609430715.203:26): table=filter family=2 entries=15 op=xt_replace pid=4407 subj=system_u:system_r:system_t comm="iptables" <5>[ 52.278549] audit: type=1325 audit(1609430715.223:27): tab le=filter family=2 entries=16 op=xt_replace pid=4412 subj=system_u:system_r:system_t comm="iptables" <5>[ 52.299842] audit: type=1325 audit(1609430715.247:28): table=filter family=2 entries=17 op=xt_replace pid=4414 subj=syste m_u:system_r:system_t comm="iptables" <5>[ 52.321002] audit: type=1325 audit(1609430715.267:29): table=filter family=2 entries=18 op=xt_replace pid=4415 subj=system_u:system_r:system_t comm="iptables" <5>[ 52.340063] audit: type=1325 audit(1609430715.287:30): table=filter family=2 entries=19 op=xt_replace pid=4420 subj=system_u:system_r:system_t comm="iptables" <5>[ 52.361228] audit: type=1325 audit(1609430715.307:31): table=filter family=2 entries=20 op=xt_replace pid=4422 subj=system_u:system_r:system_t comm="iptables" <5>[ 52.385552] audit: type=1325 audit(1609430715.331:32): table=filter family=2 entries=21 op=xt_replace pid=4424 subj=system_u:system_r:system_t comm="iptables" <4>[ 140.719362] ------------[ cut here ]------------ <4>[ 140.719393] WARNING: CPU: 4 PID: 4166 at __ioremap_caller+0x7c/0xcc <4>[ 140.719432] Modules linked in: io_registers(O) bridge nft_fib_ipv6 optee_rng tee ipv6 ipc_shm_hpe(O) ipc_shm_dev(O) virtual_ptp_clock(O) pfeng_slave(O) <4>[ 140.719491] CPU: 4 PID: 4166 Comm: sh Tainted: G O 5.10.120-rt70-eb-corbos-standard #1 <4>[ 140.719503] Hardware name: Freescale S32G399A (DT) <4>[ 140.719509] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--) <4>[ 140.719520] pc : __ioremap_caller+0x7c/0xcc <4>[ 140.719528] lr : __ioremap_caller+0x78/0xcc <4>[ 140.719538] sp : ffffffc016363c10 <4>[ 140.719541] x29: ffffffc016363c10 x28: ffffff9808164600 <4>[ 140.719552] x27: 0000000000000000 x26: 0000000000000000 <4>[ 140.719562] x25: 0000000000000000 x24: 0000000000000000 <4>[ 140.719572] x23: ffffffdd419a50b0 x22: 0068000000000f17 <4>[ 140.719584] x21: 0000000000000000 x20: 00000000809a0000 <4>[ 140.719594] x19: 0000000000001000 x18: 0000000000000000 <4>[ 140.719605] x17: 0000000000000000 x16: 0000000000000000 <4>[ 140.719614] x15: 000000557ccac140 x14: 0000000000000000 <4>[ 140.719623] x13: 0000000000000000 x12: 0000000000000000 <4>[ 140.719632] x11: 0000000000000000 x10: 0000000000000000 <4>[ 140.719641] x9 : ffffffdd473bf9cc x8 : 00000000ffffffc9 <4>[ 140.719651] x7 : ffffffdd481e46d0 x6 : 0000000000000018 <4>[ 140.719660] x5 : ffffffdd481e46d0 x4 : 0000000003200000 <4>[ 140.719669] x3 : 0000000000000001 x2 : 0000000000000018 <4>[ 140.719680] x1 : ffffffdd481e46d0 x0 : 0000000000000001 <4>[ 140.719691] Call trace: <4>[ 140.719697] __ioremap_caller+0x7c/0xcc <4>[ 140.719706] __ioremap+0x34/0x4c <4>[ 140.719714] io_registers_write+0xb0/0x13c [io_registers] <4>[ 140.719731] kobj_attr_store+0x18/0x2c <4>[ 140.719748] sysfs_kf_write+0x44/0x58 <4>[ 140.719761] kernfs_fop_write_iter+0xc0/0x188 <4>[ 140.719773] new_sync_write+0x80/0xd8 <4>[ 140.719784] vfs_write+0x114/0x138 <4>[ 140.719794] ksys_write+0x78/0xe4 <4>[ 140.719801] __arm64_sys_write+0x20/0x2c <4>[ 140.719809] do_el0_svc+0x124/0x1b0 <4>[ 140.719819] el0_svc+0x20/0x30 <4>[ 140.719835] el0_sync_handler+0xcc/0x154 <4>[ 140.719846] el0_sync+0x160/0x180 <0>[ 140.719857] Kernel panic - not syncing: <4>[ 140.719860] panic_on_warn set ... <2>[ 141.720054] SMP: stopping secondary CPUs <0>[ 142.218066] Kernel Offset: 0x1d37200000 from 0xffffffc010000000 <0>[ 142.224116] PHYS_OFFSET: 0xffffffe8c0000000 <0>[ 142.228381] CPU features: 0x00040022,20802008 <0>[ 142.232834] Memory Limit: none 分析这段kernel panic后记录的calltrace数据
最新发布
05-28
<think>嗯,用户想分析kernel panic的calltrace数据来定位问题原因,特别是涉及ioremap相关的调用栈。首先,我需要回忆一下Linux内核中ioremap的作用。记得ioremap是用来将物理地址映射到内核虚拟地址空间的,这样驱动程序才能访问硬件设备的寄存器。如果这里出问题,可能会导致非法地址访问,引发panic。 接下来,用户提供的引用内容里提到panic时内核会打印相关信息,包括调用栈。所以解析calltrace的关键是找到哪些函数调用导致了异常。比如引用[2]中的例子,有各种panic信息,可能涉及中断处理程序或空闲任务。用户的问题集中在ioremap,所以需要关注调用栈中与内存映射相关的函数,比如ioremap、ioremap_nocache等。然后,考虑常见的原因。比如,ioremap返回NULL却没有检查,或者映射后未正确释放(iounmap),或者访问了已经解除映射的地址。另外,硬件地址范围可能无效,或者多个驱动同时映射同一区域导致冲突。还有可能是缓存一致性问题,比如错误使用了不带nocache的映射。修复方案方面,首先要检查代码中ioremap的返回值是否有效,避免解引用空指针。其次,确保iounmap在适当的时候被调用,避免悬空指针。然后,核对物理地址是否正确,是否在设备规定的范围内。如果有并发访问,可能需要加锁或者重新设计映射逻辑。对于缓存问题,选择正确的ioremap版本,比如ioremap_nocache。还可以使用内核调试工具,比如addr2line将地址转换为代码行,或者kdump分析crash文件。用户可能需要具体的步骤来解析日志,比如如何从calltrace中找到关键函数,如何将地址转换为代码行。此外,相关的问题可能涉及如何预防这类问题,或者更深入的调试技巧。比如使用KASAN检测内存错误,或者检查硬件配置是否正确。需要确保回答结构清晰,分步骤说明分析方法,列举可能的原因和解决方案,并生成相关问题引导用户进一步学习。同时,引用提供的资料中的panic处理流程和Oops信息,但用户的问题更侧重于ioremap相关的调用栈分析,所以重点放在那部分。可能还需要提醒用户检查内核配置和硬件规格,确保地址映射符合预期。</think>### 解析Linux Kernel Panic日志中ioremap相关调用栈的步骤 #### 一、理解调用栈结构 在Kernel Panic日志中,调用栈(calltrace)通常包含以下关键信息: 1. **触发异常的地址**:例如`Unable to handle kernel paging request at virtual address xxxxxxxx` 2. **函数调用层级**:从底层汇编指令到高层函数调用,如`[<xxxxxxxx>] ioremap+0x1c/0x30` 3. **寄存器状态**:如`PC is at function_name+offset/0x...`,帮助定位具体指令位置[^1] #### 二、定位ioremap相关调用栈 以典型ioremap错误为例: ``` Unable to handle kernel paging request at virtual address deadbeef [<c0123456>] (ioremap_nocache+0x20/0x40) from [<c0fedcba>] (driver_probe+0x1a8/0x2d4) [<c0fedcba>] (driver_probe+0x1a8/0x2d4) from [<c0fee123>] (platform_drv_probe+0x3c/0x5c) ``` 关键分析点: 1. **非法地址**:`deadbeef`可能是未正确映射的物理地址 2. **调用层级**:`ioremap_nocache` -> `driver_probe`说明驱动初始化阶段映射失败 3. **寄存器分析**:通过`PC is at...`定位具体代码行 #### 三、常见原因与修复方案 | 原因分类 | 具体表现 | 修复方案 | |---------|---------|---------| | **无效物理地址** | 访问超出设备地址范围 | 检查硬件规格书,修正地址参数 | | **未检查返回值** | `ioremap`返回NULL后被解引用 | 添加NULL指针检查代码 | | **映射释放错误** | 访问已`iounmap`的地址 | 确保映射生命周期匹配设备使用周期 | | **并发访问冲突** | 多线程/多驱动竞争映射同一区域 | 增加互斥锁或重构映射逻辑 | #### 四、调试工具使用 1. **addr2line工具**: ```bash arm-linux-gnueabi-addr2line -e vmlinux c0123456 ``` 将地址`c0123456`转换为具体代码文件及行号[^2] 2. **KASAN检测**: 配置`CONFIG_KASAN=y`启用内存错误检测,可捕获非法地址访问 3. **Crash工具分析**: ```bash crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux vmcore bt -f -a # 查看完整调用栈 ``` #### 五、典型修复案例 **问题日志片段**: ``` BUG: unable to handle kernel NULL pointer dereference at 00000000 Call Trace: [<c0123456>] ioremap+0x1c/0x30 [<c0fedcba>] hw_init+0x45/0x120 [my_driver] ``` **修复步骤**: 1. 检查驱动代码中`ioremap`返回值处理: ```c void __iomem *regs = ioremap(phy_addr, size); if (!regs) { pr_err("Failed to map regs\n"); return -ENOMEM; // 增加错误处理 } ``` 2. 确认物理地址`phy_addr`与硬件文档一致 3. 使用`devm_ioremap_resource()`替代原生ioremap以自动管理资源
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值