解读

1. 场景定位：国内金融、支付、运营商、政务云普遍采用 TrustZone/TEE 做密钥存储、人脸识别、风控模型推理，安全内存配额由 Trust OS 统一管控，128 MB 是主流商用 SoC 的物理上限，不可通过 swap 扩展。
2. OOM 触发点：TA（Trusted Application）一次性 malloc 过大、频繁 new/delete 造成碎片、算法临时缓冲区峰值叠加、多实例并发加载。
3. 面试意图：考察候选人能否把“性能测试”视角（量化、建模、压测、调优）迁移到 TEE 受限环境，兼顾安全合规（GP TEE 规范、国密算法、国测 EAL4+）与业务 SLA。

知识点

• TEE 内存布局：REE 侧无法感知，TA 堆、栈、代码段、共享内存均统计在 128 MB 内；GlobalPlatform 规定单 TA 默认 8 MB 堆上限，需通过 ta_properties 申请扩容。
• 内存碎片度量：安全 OS 无 mmap，最佳适配（best-fit）算法在高频 alloc/free 后产生 4 KB 级碎片，测试方法为循环申请 1 K～64 K 随机块，统计最大连续空闲块 / 总空闲比。
• 算法级降存：滑动窗口复用、原位算法、分块哈希、流式对称加密（SM4-CTR）替代分组链式、Montgomery 椭圆曲线点乘预计算表压缩。
• 国密合规：SM2 签名算法需 64 字节临时点，预计算表 2880 字节，可裁剪为 1440 字节（2-bit 窗）并放 flash，计算时按需换入，牺牲 8% CPU 换 50% 内存。
• 测试工具链：optee_examples 自带 xtest 压力套件，可配置 TA 并发数；自研 Python 脚本通过 ctypes 调用 libteec，持续监控“available secure memory”节点，绘制内存时序曲线。
• 性能指标：在 128 MB 满载场景下，目标“零 OOM”且 P99 响应时间 < 50 ms（支付指令）、吞吐 > 800 TPS（二维码交易）。

答案

回答采用“测试驱动优化”四步法，先量化再动手，体现性能测试工程师的闭环思维。

第一步：建立内存基线
用 xtest 启动 1/2/4/8 并发 TA，循环执行业务主路径，通过 dmesg | grep “secure memory” 抓取实时剩余内存，输出内存消耗直方图。定位峰值占用点，记录“最大瞬时分配”与“碎片率”两项基线。

第二步：构造 OOM 故障模型
设计“内存阶梯”用例：每 100 ms 新增一个 TA 实例，每次业务分配 2 MB 临时缓存，持续 60 s。观察 OOM 触发阈值，验证是否与理论值（128 MB – 安全 OS 预留 16 MB ≈ 112 MB）吻合，确保测试可复现。

第三步：算法级优化

1. 将 RSA-2048 私钥运算改为 SM2 椭圆曲线，内存从 2.5 MB 降至 0.3 MB；
2. 大文件摘要由一次性读入 10 MB 缓冲改为 16 KB 滑动窗口，堆峰值下降 99%；
3. 预计算表放 REE 文件系统，TA 启动时 mmap 到共享内存，按需分页，安全内存常驻 < 256 KB；
4. 使用栈变量替代小堆块（< 1 KB），减少堆碎片；
5. 合并 3 次内存拷贝为 1 次，利用 attribute((packed)) 对齐，避免隐式填充。

第四步：验证与回归
在同等阶梯压力下重跑，内存峰值从 118 MB 降至 68 MB，碎片率从 35% 降到 8%，连续运行 24 h 无 OOM。P99 响应时间 42 ms，吞吐 850 TPS，满足金融 SLA。把优化 patch、测试脚本、性能报告一并归档，作为后续版本门禁（regress < 5% 内存涨幅）。

拓展思考

1. 多租户场景：同一 SoC 运行 8 家银行的 TA，如何动态配额？可引入“安全内存 cgroup”思路，Trust OS 层实现优先级驱逐，测试工程师需设计租户级压测，验证高优先级 TA 的 OOM 豁免策略。
2. 大模型下沉：人脸识别算法从 90 MB 模型压缩到 8 MB INT8，测试阶段要对比精度下降（LFW 准确率 ≥ 99.2%），性能测试需输出“内存-精度-耗时”三维 Pareto 前沿，供算法团队决策。
3. 版本回归：TEE 内核升级后，同样测试脚本出现 5% 内存上涨，如何定位？可启用 OP-TEE CFG_TEE_CORE_DEBUG 打开 memleak 检测，对比 /proc/optee/*/memstats 前后差异，快速锁定新增内核缓存。
4. 合规审计：国测 EAL4+ 要求“资源利用”项提供最坏情况内存证明，测试团队需把阶梯压测数据整理成正式报告，附在《安全目标》文档，作为过审证据。