TC397多核MCU安全分区实战：AUTOSAR OS与MPU内存隔离全解析

虚拟机分页、Hypervisor内存隔离这些概念，做服务器的工程师都不陌生。但在汽车MCU领域，很多人一听到“用MPU做安全分区”会下意识觉得是同一件事，又觉得哪里不太对——MCU上没有MMU，也没有虚拟地址，一个跑Autosar OS的三核、六核芯片，凭什么把多个安全等级的应用隔开？这个问题我在接触英飞凌TC397之后才算真正想明白。TC397用的是TriCore架构，自带硬件MPU（Memory Protection Unit），配合Autosar OS的OS-Application机制，可以在物理地址空间里直接划出互不侵犯的安全分区。这篇文章就完整讲一遍这个方案从原理到落地再到排坑的全过程，适合已经在搞AUTOSAR、正准备上多核项目，或者被安全隔离需求折磨过的嵌入式工程师。

1. 为什么MCU上也需要“虚拟机式”隔离

1.1 从Hypervisor到MPU：隔的是资源，不是地址

很多人把“虚拟化”等同于“地址转换”，其实虚拟化最核心的价值是资源隔离。放到汽车MCU场景里，隔离的目标非常朴素：一个功能模块崩了，不能把别的模块拖下水；一个低安全等级的组件访问了别人内存，系统必须在硬件层面拦下来，而不是靠写代码的人自觉。TC397没有MMU，它没有虚拟地址这一层，所以MPU做的隔离是直接基于物理地址的——给每个OS-Application划定允许访问的物理内存区间，超出区间就触发Trap。你可以把它理解成小区里给每户人家装了门禁和围栏，而不是整栋楼做虚拟门牌号。这个思路简单直接，但在多核环境下，配置和管理复杂度直线上升。

1.2 TriCore MPU的三层防线

TC397的MPU不止一块，严格来说是分层的。每个CPU核有自己的本地MPU，主要管本核上下文里的数据访问和指令访问；系统级别还有Safety MPU和总线层面的访问控制，用来管跨核访问和外设寄存器区域。实际工程里接触最多的还是CPU本地MPU，它支持为一组数据段和一组指令段分别做读、写、执行权限配置，并且区分Supervisor和User两种特权级别。这有点像操作系统里的内核态和用户态，Autosar OS正是通过把不同OS-Application放到不同特权级，再让MPU去执行边界检查。

这里必须强调一件事：MPU只管物理地址的访问权限，不管地址能不能被缓存、能不能被重映射。所以它比MMU简单，也比MMU更容易抠出性能问题——权限检查的粒度、区域的条数、重叠区域的优先级，都会直接影响实时性。

1.3 多核场景下的隔离特殊之处

TC397最多有6个TriCore核，日常讨论的“多核安全分区”通常会落到这样一个模型上：Core0跑主调度和基础软件，Core1跑一个ASIL-D级别的控制应用，Core2跑一个ASIL-B级别的诊断应用，甚至还有核跑HSM相关任务。每个核上的OS-Application都可以单独配置MPU，核与核之间通过资源域（Resource Domain）做总线级隔离。这就带来一个新的问题：一个核上的应用访问另一个核上的数据，到底算不算违规？AUTOSAR给出的答案是IOC（Inter-OS-Application Communication）加上硬件MPU双重控制，跨核访问不是直接读写内存，而是通过系统服务转发，MPU再确保这条路径上每一个环节都在白名单里。

我刚开始做这块时，以为“多核安全分区”就是每个核各配各的MPU区域，其实远远不够。真正要做的是把整个系统的访问矩阵画出来：谁在哪个核、能访问哪段内存、能否访问外设、和谁通信，然后再落到MPU配置里。少了这一步，后面调试Trap会哭。

2. Autosar OS里的分区模型：OS-Application和Trusted/Non-trusted

2.1 核心概念：OS-Application到底是什么

AUTOSAR OS里最基础的分区单位是OS-Application，你可以把它理解为一组任务、中断、调度表、计数器等内核对象和它们共享的内存资源的集合。每个OS-Application可以被标记为Trusted或者Non-trusted。Trusted的OS-Application运行在Supervisor模式，MPU对它是“睁一只眼闭一只眼”的，基本上什么都能访问；Non-trusted的OS-Application运行在User模式，MPU严格限制它的访问范围。做安全分区的第一个动作，就是把这个项目里所有的软件组件，按照安全等级和信任边界，划分成若干个OS-Application，再把不信任的标成Non-trusted，给它设置MPU区域。

Trusted和Non-trusted的这种划分，看起来跟Linux里内核态和用户态很像，但工程意义非常实际：基础软件、复杂驱动往往是Trusted的，因为它们要访问全地址空间；应用层控制算法、诊断逻辑这种业务代码，能Non-trusted就Non-trusted，因为它们本来就该被关在笼子里。

2.2 MPU区域池和配置模型

在AUTOSAR OS规范里，MPU区域不是散着配的，而是一个“区域池”的模型。系统启动时，OS把所有配置好的MPU区域汇总成一个区域表，每个区域包含起始地址、结束地址、访问权限。OS-Application的配置里引用了若干个区域的索引，OS在上下文切换时，会把当前要被调度的OS-Application所关联的区域配置加载到当前核的MPU寄存器里。这样做的好处是区域配置可以复用，多个OS-Application可以共享同一段只读代码区域，但数据区域各自独立，内存开销被压到最低。

实际在EB tresos或者别的Autosar配置工具里操作时，你会先建MPU区域（Region），然后在OS-Application的“Memory Protection”属性里把区域挂进去。工具会在生成代码阶段替你算好区域索引和地址对齐，但你最好还是自己核对一遍起始地址和大小，因为工具永远不知道你链接脚本里实际分配的变量位置。

2.3 分区之间的通信：IOC和系统调用

隔离分完之后，下一个逃不开的问题是：分区之间要交换数据怎么办？AUTOSAR的答案是IOC（Inter OS-Application Communication）。IOC支持同核内不同OS-Application之间以及跨核的通信，底层实现根据数据大小会走共享内存加锁，或者走Message Buffer。这里的关键点在于：Non-trusted的OS-Application发数据给另一个分区时，它不能直接写对方的内存，而是通过系统调用进入OS内核，由OS去完成数据拷贝和通知。MPU在这种场景下并不是“放开”访问权限，而是通过特权切换绕过了权限检查。

我在项目中遇到过一种认知误区：以为只要把MPU配好了，IOC数据收发就不需要额外关心。实际上IOC的收发缓冲区、事件标志位都在系统内存里，Non-trusted应用对它们的访问是受限的。如果配置工具没把IOC相关的共享内存区域加入该OS-Application可访问列表，一运行就是Trap。这一类问题在AUTOSAR项目里贼容易踩，因为它不是纯逻辑错误，而是配置和内存布局的联动问题。

2.4 多核绑核与分区挂载

除了内存隔离，多核安全分区还涉及“这个分区跑在哪个核上”的问题。AUTOSAR OS里每个OS-Application会绑定到一个Core，而每个Core只能运行绑到它上面的OS-Application。TC397上尽量把安全等级一致、通信频繁的应用放在同一核，跨核通信路径长、延迟波动大。我自己一般会先做一张通信矩阵，找通信次数最多的几对模块，优先把它们绑到同一核，再把安全等级高的模块单独隔离。这种做法直观上会增加MPU配置数量，但换来的是运行时更稳定的隔离效果。

3. TC397上MPU配置的实操过程

3.1 使用EB tresos配置OS-Application和MPU区域

项目里用的是EB tresos来配置AUTOSAR OS。流程一般是先建好工程、导入MCAL和OS模块，然后在OS模块里创建OS-Application，并为每个应用配置“Trusted/Non-trusted”属性和需要的MPU区域。直观操作上，你会在OS-Application的配置页里看到一个Memory Protection子页面，点进去可以新建MPU区域，填起始地址、大小和访问权限位（读、写、执行）。这里最重要的一个规则是区域大小必须是2的幂，且起始地址要对齐到这个区域大小。举个例子，如果你要保护一段4KB的RAM，起始地址必须是0xXXXXX000，不能从任意地址开始。这个约束让MPU硬件可以用掩码快速比较地址，但也强迫你在画内存布局时提前规划好对齐。

配置完成后，EB tresos会生成一份包含MPU区域表的Os_Cfg.c文件，每个区域用结构体描述，包含Base、Limit和AccessMode。实际生成的代码样例大概是这样的：

const Os_Mpu_AreaType Os_Mpu_Area_Table[OS_MPU_AREA_IDX_LIMIT] = { /* [0] 只读程序区：起始0x80000000，大小64KB */ { 0x80000000u, 0x80010000u - 1u, (Os_Mpu_AccessType)(OS_MPU_READ | OS_MPU_EXECUTE) }, /* [1] 私有数据区：起始0x70000000，大小16KB */ { 0x70000000u, 0x70004000u - 1u, (Os_Mpu_AccessType)(OS_MPU_READ | OS_MPU_WRITE) } };

注意这里Limit填的是结束地址减一，这是很多新手看代码时懵的地方。硬件比较的是“地址在[Base, Limit]区间内”才算通过，所以Limit必须写成region_size - 1而不是直接写结束地址。

3.2 链接脚本里划区域、放变量

配好MPU区域之后，实际的问题是：怎么保证代码和变量真的落在这段地址范围内？这就要靠链接脚本了。通常的做法是在链接脚本里为每个安全分区单独设置一个输出段（section），再把对应的源文件数据放进去。比如给一个Non-trusted应用划分了一块名为“.app1_data”的RAM区域，那么它的全局变量就必须放到这个section里。这一步非常容易翻车，因为变量一旦没进对section，MPU要么拦不住访问，要么一访问就被Trap。

我的做法是给每个OS-Application单独搞一个头文件，用编译属性把关键全局变量强制放到对应section：

#define APP1_VAR __attribute__((section(".app1_data"))) uint32_t app1_status APP1_VAR;

链接脚本里对应写上：

.app1_data (NOLOAD) : { . = ALIGN(4); *(.app1_data) . = ALIGN(4); } > RAM_APP1

这么一来，工程里每个模块的全局变量归属一目了然，MPU区域和实际内存高度一致，排查问题的时候省大力气。

3.3 多核启动和分区挂载顺序

TC397的启动流程是Core0先跑启动代码，初始化时钟、内存、以及基础OS，然后通过类似StartCore的方式启动Core1核，其他核依次启动。每个核启动后都会执行各自的上下文初始化，其中包括MPU寄存器加载。Autosar OS在启动阶段会调用Os_InitMpu，OS会根据每个核上挂载的OS-Application把对应的MPU区域表加载进去。

这里有一个实操细节：如果Core1上有Non-trusted的OS-Application，那么Core1初始化MPU前，所有在Core1上执行的代码必须在可信上下文中完成，否则一开MPU可能把自己给拦了。所以建议先把所有OS-Application的MPU配置准备好，在系统启动早期统一加载，而不是边启动边配置。我在实际项目里就碰到过Core1上由于MPU开启顺序不对，导致调度器第一条切换指令就触发MMU Trap（TriCore把内存保护异常归到MMU Trap类），最后只能去查Trap的TIN号才能定位。

Trap定位的方法，简单说就是在Trap处理函数里读当前的Trap Class和TIN，比如TriCore的MMU Trap会带着一个子码，指示是数据访问还是指令访问、是哪个地址、是读还是写。拿到这些信息后反查MPU区域表，基本能锁定是哪个应用越界了。这一招在调试前期极其有用。

3.4 调试MPU问题的三板斧

第一板斧是先把Trap打印出来，包括PC、Trap Class和TIN。第二板斧是把MPU区域表dump出来，核对实际地址。第三板斧是关掉优化复现一次，因为编译器优化可能会把某些访问挪到MPU保护范围之外，造成时好时坏的Trap。曾经定位过一个非常诡异的问题：Non-trusted应用读自己的数据变量，有时候Trap有时候正常，后来发现是编译器生成了超过寄存器位宽的访问指令，访问范围被错误扩大，越过了MPU区域边界。改成volatile并强制走LDR/STR单字访问后问题消失。

4. 常见问题与排查技巧实录

4.1 常见Trap类型和对应根因

我把实际调试中遇到频率最高的几种异常整理了一下，如下表所示：

这张表能帮你快速缩小范围，但还是得回到MPU区域配置和链接脚本里查根因。

4.2 配置时最容易忽略的三个细节

第一，MPU区域的对齐约束。区域大小是2的幂已经是常识了，但很多人会忽略起始地址对齐同样是按“区域大小”对齐，而不是按4字节或者16字节对齐。比如区域大小64KB，起始地址必须是64KB的整数倍。配置工具一般会自动对齐，但手动改链接脚本时经常栽在这。

第二，只读区域和代码执行权限。程序区要同时配读和执行，很多人只给了READ忘记EXECUTE，结果任务一跑起来就跳到Trap里。配合上写保护，才能真正防住代码被篡改到非可信状态。

第三，MPU区域数量有限。TC397每个核的本地MPU区域数量是有上限的，大约十几个数据区域和指令区域。如果你把一个OS-Application的内存拆得太碎，区域数量很容易耗尽。解决办法是把同一应用的内存尽量连续，能用一个大区域就绝不拆成三个小区域。

4.3 性能和隔离之间的平衡

MPU校验是在总线访问阶段做的，对运行时间的影响比预期小很多，但也不是零开销。特别是在数据通路非常频繁的实时控制环里，频繁访问多个分散区域可能让MPU区域匹配逻辑成为瓶颈。有人会为了性能把所有内存放进一个大区域，这就完全失去隔离意义了。我的习惯是保证“故障传播路径被切断”这个最低要求的前提下，尽量用较大的连续区域。换句话说，MPU隔离的核心目标是防止故障扩散，而不是把每个变量都单独保护起来。

另外还要注意多核并发访问共享外设寄存器的场景。MPU除了保护内存段，还能保护外设寄存器的映射空间。TC397的很多外设寄存器是全局映射的，如果多个核上的Non-trusted应用都要操作同一个外设，就得额外做外设访问权限管理和总线访问仲裁，不能光靠MPU扛。这个层面再深一点就是Resource Domain的配置了，属于多核MCU设计的进阶话题。

4.4 从配置到评审：一个复用性很高的自检清单

我每次做完MPU分区配置，都会按下面几条过一遍：

• 每个Non-trusted OS-Application是否至少包含自己的栈段、数据段和代码段？
• 程序区是否配置了READ+EXECUTE，数据区是否配置了READ+WRITE？
• 所有区域起始地址和大小是否满足对齐规则？
• 是否所有跨分区通信消息都走IOC或系统调用，有没有直接指针访问？
• 系统启动阶段加载MPU的代码是否全程在可信上下文？
• 中断服务函数归属的OS-Application是否拥有访问其所需全部内存的权限？
• 每个核上的MPU区域表是否只包含本核运行应用所需区域？

这套清单看着琐碎，但每一条背后都有一次项目事故当学费。安全分区这种东西，配置错了不一定马上崩，往往是在某个极端运行条件下才炸出来，而且一炸就是整车的安全功能失效。所以宁可前期多花点时间核对，也别等到台架测试或者路试的时候去追Trap。

5. 写在最后的一点体会

做了几个项目的TC397多核安全分区之后，我最大的感觉是：MPU本身并不难懂，难的是把系统架构、内存布局、任务调度、通信机制这些散落的东西，统一到一张访问控制矩阵里。虚拟机那套隔离思路给了我们很好的思考框架——“什么该被信任、什么不该被信任，边界画在哪”，但在MCU上落地时，你必须亲手去处理物理地址、section、对齐、特权级这些非常底层的东西。建议第一次做分区功能的工程师，先拿一个小工程把Trusted/Non-trusted切换、MPU区域配置、Trap定位链路整个跑通，再往真实项目里推广。这个过程会踩不少坑，但踩完之后你对AUTOSAR OS的理解绝对会上升一个层次。TC397的硬件保护能力本身非常强，真正决定安全分区成败的，往往是配置时的严谨程度和对每一个地址的掌控力。