TEE - TLK需求分析

最新推荐文章于 2024-06-13 18:01:40 发布

昵称：RainMaker

最新推荐文章于 2024-06-13 18:01:40 发布

阅读量1.7k

点赞数

分类专栏： Security OS 文章标签： TEE security TLK

本文链接：https://blog.csdn.net/mengkevin/article/details/72637817

版权

Security OS 专栏收录该内容

5 篇文章

订阅专栏

本文详细介绍了基于LK开发的TLK安全操作系统，包括其模块组成、与GP规范的关系及实现方式。TLK由多个模块构成，如TLKCA库、TLKTALibrary等，支持会话管理和内存操作等功能。此外，还探讨了TLK与GP规范之间的差异及其二次开发需求。

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

TLK（trust light kernel)是基于LK开发的security OS，印象中是nvidia的安全小组开发的。n年前，曾把TLK作为移植security OS的候选之一，当年做了一些研究。

TLK 分析

1. TLK现状

TLK包括如下6大模块:

TLK CA Library:
- Open session API
- Close session API
- Invoke session API
TLK TA Library:
- 和平台相关操作API,比如cache操作,地址映射操作等
- Memory分配/释放等API
- 加/解密API
- 平台相关的密钥的获取API
- RTC API
- 文件操作API
- Task loader API
- Open session API
- Close session API
- Invoke session API
- Create/ destroy instance API
TLK Linux Driver:
- 提供TLK CA和Monitor之间的数据通道
- Linux向TLK发起电源管理方面的请求
TLK Kernel:
- 内核对象操作,包括event,thread,task,mutex,semaphore,timer
- 平台相关操作,包括CPU,中断,电源管理等等
- 驱动,包括fb,key,net,pmic,usb
- Kernel lib
- Smc handler&disptach
- System call
- Session操作,task操作
Monitor:用于从REE恰换至TEE
Platform Opreation:和平台相关的操作
- cache操作,地址映射操作等
- 电源管理

模块之间的关系如下图所示:

这里写图片描述

上图中的TA和CA需要用户自己实现。TLK源生代码中只包含了部分APP用例，例如shell等。

在初始化阶段，TLK会为静态链接进image的每个TA创建task和user thread，然后在Task空间加载TA并运行thread。
对于APP，会为每个APP创建kernel thread并调用APP的入口函数。

2. TLK和GP

TLK和GP的关系简单描述如下图：

这里写图片描述

TLK当前只是提供了GP框架和相关的lib，实现方式和API源型并没有严格符合GP规范要求。需要在TLK上做二次开发，才能满足GP规范。

2.1 Trust Core Framework(TCF)需求分析

GP的TCF的框架如下图所示：

这里写图片描述

TA和TLK TA Library的关系如下图：

这里写图片描述

具体实现如下图：
这里写图片描述

在编译阶段,TA链接libtlk_service,以其main函数作为entry；在运行阶段，kernel在TA task环境中调用入口函数main。main实现为service方式，即等待请求，接收请求后根据所传参数调用对应的TA实现的session/instance函数。

TLK支持的session/instance回调函数共有5个，和GP的TA interface对应,如下：

    TA_CreateEntryPoint         <-> te_create_instance_iface
    TA_DestroyEntryPoint        <-> te_destroy_instance_iface
    TA_OpenSessionEntryPoint    <-> te_open_session_iface
    TA_CloseSessionEntryPoint   <-> te_close_session_iface
    TA_InvokeCommandEntryPoint  <-> te_receive_operation_iface

但是双方的函数参数并不一致。如果需要支持GP规范，则需要在Tlklib中实现te_*函数， te_*将TLK参数转换为GP参数要求，并调用TA_*；而TA_*则由TA实现。

2.2 Internal client API需求分析

TLK在tlklib_service定义并实现了相关函数te_*，和GP对应关系如下：

    TEE_OpenTASession       <-> te_open_session
    TEE_CloseTASession      <-> te_close_session
    TEE_InvokeTACommand     <-> te_launch_operation

但同样，函数的参数类型和返回类型不一致。需要在tlklib_service中实现TEE_*函数，将其实现为te_*函数的封装。

同样，对于CA，已经在tlklib_client中实现te_*，需要实现对应的GP函数，对应关系如下：

    TEEC_OpenSession    <-> te_open_session
    TEEC_CloseSession   <-> te_close_session
    TEEC_InvokeCommand  <-> te_launch_operation

同样，函数的参数类型和返回类型不一致。需要在tlklib_client中实现TEEC_*函数，将其实现为te_*函数的封装。

2.3 Cancellation functions需求分析

TLK没有实现Cancellation相关的函数。需要在tlklib_client、tlklib_service、tlk kernel，linux driver中增加相关功能。

根据GP规范，Cancellation在以下2种场景做不同的处理：

操作请求还未传递至TA
如果发起了Cancellation操作，只需将此操作请求从请求队列中去除即可
操作请求已至TA
将TA task置为cancelled状态，这会影响一些可以cancellable的函数，比如TEE_Wait。TA可以通过设置自己的属性屏蔽client发起的Cancellation操作。

如果假设操作请求的传递是原子性的，则可以只处理第2种情况。需要在tlklib_client中实现：

        TEEC_RequestCancellation

将TA task置为cancelled状态。

在tlklib_service中实现如下API：

        TEE_GetCancellationFlag
        TEE_UnmaskCancellation
        TEE_MaskCancellation

用于设置/读取 TA自己的Cancellation屏蔽属性。

在cancellable函数实现时，需要一并考虑cancelled状态和Cancellation屏蔽属性，以便确认操作请求是否有效。

2.4 Property access functions需求分析

根据GP规范，可以设置/获取当前TA属性、当前CA属性，TEE系统属性，且属性名都有各式要求。TLK当前只有property access功能框架，仅实现了部分property的读取，实现如下：

这里写图片描述

如需要支持GP规范，需要做如下增强：

当前TA Property set扩展
TLK支持TA的manifest属性读取，当前可配的属性如下：

  typedef enum {
    OTE_CONFIG_KEY_MIN_STACK_SIZE   = 1,
    OTE_CONFIG_KEY_MIN_HEAP_SIZE    = 2,
    OTE_CONFIG_KEY_MAP_MEM      = 3,
    OTE_CONFIG_KEY_RESTRICT_ACCESS  = 4,
    OTE_CONFIG_KEY_AUTHORIZE    = 5,
    OTE_CONFIG_KEY_TASK_ISTATE  = 6,
} ote_config_key_t;

需要在manifest扩展属性。根据GP，需要支持如下的属性：

gpd.ta.appID
gpd.ta.singleInstance
gpd.ta.multiSession
gpd.ta.instanceKeepAlive
gpd.ta.dataSize
gpd.ta.stackSize
gpd.ta.version
gpd.ta.description

其中gpd.ta.appID需要从tlk kernel获取，其他直接从TA本身获取。

TEE属性支持
TLK当前te_get_implementation_property的实现是空函数，需要tlk kernel增加对TEE属性的读取功能，属性包括gpd.tee*等。并在tlklib_service中增加对属性读取的系统调用。
在tlklib_service中实现GP定义的TEE_*Property*等函数，实现对te_*函数的封装。

由于此部分功能比较独立，也和平台无相关性，可以参考Op-tee在tlklib_service和Tlk kernel中实现property access功能。

2.5 Memory management functions 需求分析

TLK在tlklib_service中实现有te_mem_*等memory分配/释放等函数。可以封装te_mem相关的API，实现GP规范要求的memory API。

TLK实现有ote_set_instance_data/ ote_get_instance_data API，可以利用它们实现GP所需的如下2个接口：

TEE_SetInstanceData
TEE_GetInstanceData

但GP的TEE_CheckMemoryAccessRights需要自己实现，TLK没有提供相关的源型。

3. 功能实现

TLK的CA和TA实现为client/server关系，REE中的CA在TEE中都有对应的TA。TLK中缺失的功能可以通过CA/TA的方式实现。

这里写图片描述

4. lib

4.1 client lib

Lib包含了client和service这2部分：

Client是供android CA调用；
Service是供TLK的TA调用;

Client是通过/dev/tlk_device 接口和Linux交互。包含有如下3个API：

te_open_session：TE_IOCTL_OPEN_CLIENT_SESSION
te_close_session：TE_IOCTL_CLOSE_CLIENT_SESSION
te_launch_operation：TE_IOCTL_LAUNCH_OP

Client被编译为静态库libtlk_common。

4.2 service lib

Service lib的session接口实现在ote_command.c中，service中的其他lib调用session接口实现和TLK kernel的交互。

Service是利用syscall和TLK kernel交互。使用的是bionic\libc\arch-arm\syscalls下的接口。read接口示例如下：

    ENTRY(read)
        mov     ip, r7
        ldr     r7, =__NR_read
        swi     #0
        mov     r7, ip
        cmn     r0, #(MAX_ERRNO + 1)
        bxls    lr
        neg     r0, r0
        b       __set_errno
    END(read)

可见r7= 服务号

#define __NR_SYSCALL_BASE 0
#define __NR_read (__NR_SYSCALL_BASE+ 3)

Tlk kernel会根据相应的参数服务请求。

Service被编译为静态库libtlk_service。

te_create_thread_session中处理task->props.multi_instance条件时，没有将新创建的session->thread附加到task中，session->thread默认是kernel thread。

5 附几张TLK的结构图：

这里写图片描述