OP-TEE项目中I2C驱动开发的技术思考

背景概述

在嵌入式安全领域，OP-TEE作为可信执行环境(TEE)的开源实现，广泛应用于各类安全关键场景。近期在将OP-TEE集成到基于TI芯片的Android解决方案时，遇到了一个特殊需求：需要在OP-TEE内部实现完整的I2C总线驱动功能，包括主从模式切换等基础特性，并且要求这些代码能够被上游项目接受。

技术挑战分析

现有架构考察

OP-TEE项目中已经存在多种I2C相关实现，分布在不同的代码路径中：

1. 核心驱动目录下的各平台I2C实现
2. 专用I2C驱动目录
3. 加密协处理器SE050的I2C胶水代码
4. 通过RPC机制与外部系统通信的I2C接口

设计考量因素

1. 安全性边界：所有I2C操作必须完全在TEE环境中完成，不能委托给非安全环境(如Linux内核)
2. 功能完整性：需要支持主/从模式切换、读写操作、速率配置等基础功能
3. 上游兼容性：代码结构和接口设计需要符合OP-TEE项目的代码规范

技术方案探讨

方案一：直接驱动实现

在core/drivers/目录下新增平台特定的I2C驱动(如ti_i2c.c)，同时提供配套的PTA(伪TA)接口，向可信应用(TA)暴露I2C功能。这种方案完全符合"所有操作在TEE内完成"的要求，但存在以下考量：

• 缺乏明确的使用场景，可能难以证明其必要性
• 直接向TA暴露底层I2C接口可能带来安全隐患
• 需要仔细设计PTA接口的权限控制机制

方案二：服务型架构

构建分层的安全服务架构：

1. 底层驱动层：实现平台特定的I2C控制器操作
2. 中间服务层：通过PTA提供受控的I2C访问接口
3. 应用层：特定功能的TA(如加密服务)通过标准接口使用I2C功能

这种架构更符合安全设计原则，但实现复杂度较高。

上游接受度评估

从技术角度看，纯粹的I2C驱动代码若无明确使用场景，较难被上游接受。更可行的路径是：

1. 将驱动作为特定加密协处理器的配套代码
2. 设计为通用的安全I2C访问控制服务
3. 提供完整的测试用例和使用文档

实施建议

1. 分阶段实现：先完成基础驱动，再构建上层服务
2. 接口标准化：遵循OP-TEE现有的驱动模型
3. 安全评估：特别注意直接I2C访问的安全影响
4. 用例驱动：最好有具体的硬件用例作为开发依据

总结

在OP-TEE中实现完整的I2C驱动支持技术上可行，但需要仔细考虑架构设计和上游接受度问题。建议采用服务型架构，通过PTA提供受控的访问接口，同时寻找或构建具体的使用场景来证明代码的必要性。开发过程中应特别注意安全边界和接口设计，确保符合OP-TEE项目的安全理念和代码规范。