日志系统设计：TEE日志缓冲区机制、日志级别与标签规范

日志这东西，说白了就是TEE的“黑匣子”。我刚开始做TEE适配时，总觉得日志嘛，printf一下不就完了？结果第一次在真实硬件上跑，Secure World里死活看不到输出，调试像瞎子摸象。后来才明白——TEE的日志系统，跟普通Linux应用完全是两码事。

为什么TEE日志不能直接“print”

你想想看，TEE运行在安全世界，它没有标准输出，没有文件系统，甚至没有中断给用户态。那日志往哪写？

• 共享内存：TEE和REE（富执行环境）之间划一块固定区域，TEE往里写，REE侧的服务（比如OP-TEE的`tee-supplicant`）定时读出来。
• 硬件FIFO：有些SoC提供专门的调试硬件，比如ARM的CoreSight，日志直接走硬件trace。
• 串口直出：开发板上最粗暴的方式，TEE直接操作UART寄存器往外吐。但生产环境绝对不能用。

我个人习惯，在项目初期先用共享内存方案。原因很简单——不需要额外硬件，纯软件就能搞定，调试起来最灵活。

日志缓冲区机制：环形缓冲区的陷阱

TEE的日志缓冲区，几乎清一色都是环形缓冲区。为什么？因为TEE内存金贵，不能像Linux那样随便malloc几MB。环形缓冲区固定大小，写满了就覆盖最旧的数据。

但这里有个坑——我踩过。

所以，设计缓冲区时，我建议至少考虑以下几点：

下面是一个典型的TEE环形缓冲区结构，我用C语言描述一下核心逻辑：

/* TEE日志环形缓冲区 */
#define LOG_BUF_SIZE  (32 * 1024)  /* 32KB */

struct tee_log_buffer {
    volatile uint32_t head;   /* 写指针 */
    volatile uint32_t tail;   /* 读指针 */
    volatile uint32_t flags;  /* 状态标志 */
    uint8_t data[LOG_BUF_SIZE];
};

/* 写入日志（简化版） */
void tee_log_write(struct tee_log_buffer *buf, 
                   const uint8_t *msg, uint32_t len) {
    uint32_t head = buf->head;
    uint32_t next;

    for (uint32_t i = 0; i < len; i++) {
        next = (head + 1) & (LOG_BUF_SIZE - 1);
        /* 如果写满，覆盖最旧数据 */
        if (next == buf->tail) {
            buf->tail = (buf->tail + 1) & (LOG_BUF_SIZE - 1);
        }
        buf->data[head] = msg[i];
        head = next;
    }
    buf->head = head;
}

嗯，这里要注意——我用了volatile，因为TEE里可能有多个CPU核心同时访问缓冲区，编译器优化会搞乱内存顺序。实际项目中，你还需要加内存屏障（DMB/DSB指令）。

日志级别：DEBUG到FATAL的取舍

日志级别这东西，每个团队都有自己的定义。但TEE场景下，我建议严格遵循以下四级：

为什么没有FATAL？我个人习惯把FATAL归到ERROR里，加一个特殊标志位。因为TEE里“致命错误”往往意味着整个安全世界要重启，单独一个级别反而增加复杂度。

日志标签规范：一眼看出谁在说话

TEE里多个TA（可信应用）同时运行，日志混在一起根本分不清谁是谁。所以标签规范是刚需。

我建议的标签格式：

[模块名:子模块] 级别 消息

/* 示例 */
[TA:payment] INFO  Session opened, user_id=1024
[CORE:mm]    ERROR Page allocation failed, size=4096
[DRV:uart]   WARN  TX buffer full, retrying

标签规范的核心原则：

• 模块名：大写，不超过8个字符。比如TA、CORE、DRV、SVC。
• 子模块：小写，具体功能名。比如payment、mm、uart、crypto。
• 分隔符：统一用冒号+空格，不要用中划线或下划线。
• 级别：固定4字符右对齐，比如INFO、WARN。

为什么这么严格？因为日志分析工具需要解析这些标签。我见过一个项目，日志格式五花八门，最后写了个200行的Python正则才勉强解析——那叫一个痛苦。

整体架构：一张图说清楚

下面这张图，是我对TEE日志系统整体设计的理解。它把缓冲区、级别、标签、输出路径串在了一起。

从这张图你能看到，日志从TA、Core、驱动层产生，经过收集层格式化、过滤、加标签，写入环形缓冲区，最后通过不同通道输出到REE或调试接口。每一层各司其职，互不干扰。

实战中的几个“坑”

最后，分享几个我实际项目中踩过的坑，希望能帮你少走弯路：

1. 日志死锁：在中断处理函数里写日志，结果日志函数里用了自旋锁，中断又来申请同一把锁——直接死锁。解决方案：中断上下文用无锁队列，或者用原子操作直接写缓冲区。
2. 日志泄露敏感信息：DEBUG日志里打印了密钥材料的hex dump，上线前忘记关掉。嗯，这个后果你懂的。我现在的做法：所有日志输出前过一遍“敏感信息过滤器”，正则匹配密钥、证书、PIN码等关键词，直接替换成[REDACTED]。
3. 时间戳精度：TEE里没有gettimeofday，只能用硬件计数器（比如ARM Generic Timer）。但不同核心的计数器可能不同步。我建议在日志收集层统一用某个核心的计数器，避免时间倒流。