我有一个为基于 STM32-L552ZE Cortex M-33 的 MCU 编写的应用程序，该 MCU 使用 TrustZone-M。
两个世界都有一个main.h，main.c，并且两个 wolds 的头文件都声明一个变量foo（即安全main.h和非安全main.h声明foo）。
在我看来，这应该是好的，因为我了解 TrustZone 的方式（诚然，我更多地来自 TrustZone-A，SGX 世界）让我相信两个世界是相互的，并且只通过一个明确定义的接口进行交互（通过 NSC 区域的安全 / 非安全函数调用）。
不幸的是，在调试我的代码时，我注意到不安全世界对foo的写入被忽略了。通过检查foo的地址，它位于0x3...，我注意到它被分配在安全世界的 SRAM 中。在取消注释安全世界的foo声明后，其余内容保持不变，0
我知道 TrustZone-M 通过内存地址实现分离，尽管我会假设链接器足够聪明来区分foo的两个实例。
澄清：
为了使情况更清楚，以下是代码的摘录：
安全主.h：
#ifndef __MAIN_H
#define __MAIN_H
/* Includes */
#include "stm32l5xx_hal.h"
#include "secure_nsc.h" // Header file declaring the functions into secure world
/* Private includes*/
/* USER CODE BEGIN Includes */
#include "inttypes.h"
#include "string.h"
/* USER CODE END Includes */
...
typedef struct ringbuf{
volatile int16_t prod_ind;
volatile int16_t cons_ind;
volatile int16_t isr_ctr;
volatile bool_t empty;
byte_t buf[RBUF_LEN];
}ringbuf_t;
ringbuf_t foo;
...
#include "helper.h"
#endif /* __MAIN_H */
不安全的 main.h：
#ifndef __MAIN_H
#define __MAIN_H
/* Includes */
#include "stm32l5xx_hal.h"
#include "secure_nsc.h" /* For export Non-secure callable APIs */
/* Private includes */
/* USER CODE BEGIN Includes */
#include "inttypes.h"
#include "string.h"
/* USER CODE END Includes */
...
typedef struct ringbuf{
volatile int16_t prod_ind;
volatile int16_t cons_ind;
volatile int16_t isr_ctr;
volatile bool_t empty;
byte_t buf[RBUF_LEN];
}ringbuf_t;
ringbuf_t foo;
...
#include "helper.h"
#endif /* __MAIN_H */
helper.h，即安全的和不安全的，都有以下声明（定义存在于它们各自的 helper.c 文件中）：
bool_t rb_produce_one(ringbuf_t* rb, byte_t ibyte);
这个函数rb_produce_one是非安全世界用来访问其 ringbufferfoo的函数。
Securemain.c不使用其foo实例（但稍后将使用它）。
非安全main.c通过在helper.h中声明并在helper.c中定义的函数访问foo（同样，helper.h，helper.c存在两次，一次在安全世界，一次在非安全世界）。
本站系公益性非盈利分享网址，本文来自用户投稿，不代表边看边学立场，如若转载，请注明出处
评论列表（57条）