汽车信息安全–S32K3的HSE如何与App Core通信？

汽车安全 2个月前 admin

38 0 0

1.S32K3 网络安全架构

2. MU的通信流程

2.1 总体描述

2.2 Host 消息类型

2.3 寄存器概述

2.4 流程实例

3.小结

在之前，我们聊过英飞凌TC3xx和瑞萨RH850-F1KM系列HSM和Host的通信方式。值得一提的是，上述二者通信方式竟出奇的一致，并且在寄存器命名上也是值得细细品味。

既然如此，那么另一家大厂NXP是如何设计Host和Hsm的通信方式呢？为此，我也粗浅研究了S32K3数据手册的相关内容，并进行整理，为我的汽车网络安全知识库补充弹药。

1.S32K3 网络安全架构

在NXP的公开手册我们可以看到，与目前市面上大多数车规MCU网络安全架构一致，S32K3也分为Host Domain和Secure Domain，如下图所示

可以看到，S32K3中的HSE支持EVITA-FULL等级，并且还提出了HSE 固件升级的方案（BAF）。

Host core与Hse Core二者通信是通过特定的接口，这个接口被称之为Messaging Unit，如下图：

进一步的，MU不仅可以用在HSE core和Host core之间关于数据、状态等信息的交互，还可以用在不同Host core之间的数据同步。

MU的总体框架如下：

MU是由A、B两侧的寄存器组共同组成，下面以单侧寄存器进行描述具体内容：

TX/RX寄存器：4个发送寄存器和4个接受寄存器，用于A、B两侧的数据传输；

StatusControl寄存器：控制和观察两端事件、传输等状态的寄存器

SyncControl寄存器：由于Host和Hse时钟域不同，需要在数据传输时进行同步处理，该寄存器主要做这事儿。

Generate Int：中断处理

2. MU的通信流程

2.1 总体描述

有了上面MU的框架，我们就可以简单来画一下这二者的通信流程。

Host Core通过Application Space中的Tx寄存器向Hse Core发送数据，Hse拿到数据处理完毕后再通过HSE Space的Tx寄存器返回响应给Host Core，这就是一个简单的通信方式。

但是这里面有一个问题，根据TRM的描述，单侧TX寄存器总共才4个，一次性可以传输的数据最多也就4*4 =16Byte，如果要多次传输的话，还需等HSE Core的接收完成响应Flag。

很明显这无法满足SecOC对于数据校验的实时性要求。我都想到这个问题，NXP也肯定想到了呀，因此它继续定义了共享内存的机制用于解决该问题，也就是第一张图上的单向interface（它的大小和访问权限需要由HSE指定）。

2.2 Host 消息类型

为了满足Host侧不同应用场景的需求，对于Host消息类型，NXP做出了如下分类：

短消息

所谓短消息，即1-4个字的消息，host将4个字的消息写入4个Tx寄存器中，然后向Hse Core设置对应中断请求通知其来取数据，这样效率较高

数据信息描述消息

由于要处理的数据太长，没办法一次性发送完毕；Host可以把该数据放在约定好的共享内存，然后把该数据的存放地址、数据长度等信息通过Tx寄存器发送给Hse，Hse可依据上述信息到指定共享内存取数据进行处理

固定长度数据消息

固定长度数据消息可以放在共享内存，如数据较短也可以使用短消息方式进行处理，区别在于这二者的执行效率

程序状态消息

该消息因为表征状态，而状态一般使用bit就可以进行描述，因此NXP定义了几个寄存器的bit位用于表征

2.3 寄存器概述

在我们了解了MU的总体框架和消息分类后，我们就需要来看MU里哪些寄存器可以用来满足上述消息的传递。根据芯片手册，MU的寄存器总体框架如下：

从上图可以看到，MU把寄存器分为了三大类：数据传输寄存器（TRRR）、控制寄存器（CR）和状态寄存器（SR）。

数据传输寄存器用于发送和接收数据。

通过上图大家可以发现，一侧的TR对应的是另一侧的RR，而根据手册描述，往TR写入数据会直接覆盖掉对应RR的内容；

因此在使用时要重点关注这两个寄存器的状态，所以就出现了TSR(Transmit Status Register)和RSR两类状态寄存器。

TSR4个bit位对应4个TR的状态，当有数据写入到某个TR时，TEx会置0；当另一侧通过对应RR读取数据后，TEx置1，表示一侧又可以继续往下写了。

一般来讲，我们在使用的时候通常想的是把4个TR写满后再通过中断告诉Hse来获取数据；但如果短消息只有1个byte，这个时候就只需要写1个TR，并通过设置TCR相应的发送中断即可（前提是另一侧对应RCR的中断也要开启）。

再进一步的，如果只是某个事件的通知，根本不需要数据，就可以使用GCR(General-purpose Control Register ) 直接产生一个通用中断请求到另一侧内核。

因此，我们可以总结出单侧的主要寄存器列表(没有按offset整理)如下：

寄存器名	作用
Transmit Regster(TR0-TR3)	传输数据到另一侧
Transmit Control Register(TCR)	控制到另一侧的发送中断使能
Transmit Status Register (TSR)	表示一侧的TR是否为空
Receive Register (RR0 – RR3)	读取TR传递的数据
Receive Control Register (RCR)	控制一侧的接收中断使能
Receive Status Register (RSR)	表示一侧的RR是否写满
General-purpose Interrupt Enable Register (GIER)	控制通用中断使能
General-purpose Control Register (GCR)	向另一侧发送通用中断请求
General-purpose Status Register (GSR)	表示中断请求是否pending
Flag Control Register (FCR)	控制写入另一侧的Flag标志
Flag Status Register (FSR)	表示另一侧对于一侧的Flag
Control Register (CR)	设置MU的复位
Status Register (SR)	表示MU的总体状态

2.4 流程实例

上面讲了那么多的抽象概念，我们还是以短消息为例，看看实际的通信流程。

A向TR写入数据，同时该数据被映射到B的RR（但此时B还是不知道）；

写入数据后，硬件会自动清除A侧的TSR.TE，表示A侧对应TR此时不为空，不能写数据；同时B侧的RSR.RF会置1，表示B侧对应RR有数据了，可以读了；

当B侧RSR.RF置1后，会立即产生一个接收中断请求给内核B；

内核B响应请求，开始从RR读取数据；

当完成数据读取后，硬件自动将B侧RSR.RF清0，A侧TSR.TE置1，分别表示RR为空，TR为空；

当A侧TSR.TE为1时，产生发送请求给内核A，这样就可以继续写入数据到TR了。