The results of this project were published in the paper entitled SoK: Where’s the “up”?! A Comprehensive (bottom-up) Study on the Security of Arm Cortex-M Systems in the USENIX WOOT Conference on Offensive Technologies 2024. If you want to cite our paper in your work, please use the following BibTeX entry.

@inproceedings{tan24sok,
  author = {Tan, Xi and Ma, Zheyuan and Pinto, Sandro and Guan, Le and Zhang, Ning and Xu, Jun and Lin, Zhiqiang and Hu, Hongxin and Zhao, Ziming},
  title = {{SoK: Where's the ``up''?! A Comprehensive (bottom-up) Study on the Security of Arm Cortex-M Systems}},
  booktitle = {USENIX WOOT Conference on Offensive Technologies},
  year = {2024}
}

This project tests all kinds of faults, e.g. memory access violations, on a Cortex-M system considering different setups of privilege levels, TrustZone, MPU, SAU, IDAU, MPC, PPC.

• Board: Arm MPS2+
• IDE: Keil
• Armv8-M:
  • image: Cortex-M33 (AN505: Cortex-M33 with IoT kit FPGA for MPS2+)
  • project: IOTKit_CM33_S_NS
• Armv7-M:
  • image: Cortex-M3 (AN491: SSE-100 IoT subsystem for Cortex-M FPGA for MPS2+)
  • project: CM3_Blinky

This is a learning purpose project, not automatically tests.

Users are recommended to use Keil IDE to interact with those test cases, observe the memory, set up breakpoints, etc.

Users are recommended to read the IOTKit_CM33_S_NS/Update_log.md to learn the details of each test case.

File tree

IOTKit_CM33_S_NS
|--IOTKit_CM33_ns
  |--DebugConfig/   /* debug configurations for compiler */
  |--RTE/           /* startup and partitioning */
  |--...
  |--main_ns.c      /*  main function to call the test_cases */
  |--Secure_Function    /* non-secure-callable functions */
  |--test_case_ns.c /* all test cases are declared in this file */
  |--test_ns.c      /* provide basic functions the test cases need */
  |--test_ns.h      /* all macros are defined in this file */
|--IOTKit_CM33_s
  |--DebugConfig/   /* debug configurations for compiler */
  |--RTE/           /* startup and partitioning */
  |--...
  |--main_s.c       /*  main function to call the test_cases */
  |--Secure_Function    /* non-secure-callable functions */
  |--test_case_s.c  /* all test cases are declared in this file */
  |--test_s.c       /* provide basic function the test cases need, including fault handlers */
  |--test_s.h       /* all macros are defined in this file */
|--...
|--README.md
|--Update_log.md

*******************

CM3_Blinky
|--Out/             /* output objects */
|--RTE/             /* startup and device files */
|--Blinky.c         /* tmplate blinky file */
|--test_cases.c     /* provide basis functions the test cases need */
|--test.h           /* header file for test cases */
|--test.c           /* test cases */
|--...

• IDE: MDK-ARM
• Image: For this test, we use Cortex-M33 IoT Kit Imgae on MPS2+. Refer to link to setup the image and the debugger.
• Open the multi project workspace: IDE->File->Open->IOTKit_CM33_S_NS->IOTKit_CM33_s_ns.uvmpw
• Batch build, setup the debugger as CMSIS-DAP

Our test cases are developed based on IOTKit_CM33_S_NS example code.

• For each test case, there are macros in the test/test_s/ns.h file. To test those cases, you can change the value in test_cases_ns/s.c: test_cases() function.

void test_cases()
{
	test_cases_s(TEST_SWITCH_NS);
}

• Then result will show on the LCD screen on the board we use.

The example code suite includes the following components:

1. Helper and configuration functions. These functions provide a C language interface to configure system and peripheral registers. The current version include:

   • exception handlers that retrieve detailed fault information;
   • functions to enable and disable data and instruction cache;
   • stack dump function that prints out regular stack and exception stack contents;
   • helper functions to configure and control iv) MPU; v) SAU; vi) MPC; vii) DWT; viii) MTB.

2. Test cases to demonstrate how to use hardware features. The current version include the following test cases:

   • change xPSR;
   • legal and illegal memory accesses;
   • TT instruction examples;
   • hardware stacking and unstacking with (m33) and without TrustZone (m3);
   • instruction tracing with MTB;
   • performance measurement and data access monitor with DWT;
   • state transition tests and performance measurement.

This section explains the macros and tests. Projects on Cortex-M33 uses TrustZone, there are two projects including the project in the secure state and the non-secure state.

Helper and configuration functions

Test Cases

For more details, please refer to Update_log.md

ATTENTION: Cortex-M3 does not equip with MTB.

Most test cases are checked on Cortex-M33, the project on Cortex-M3 only shows how to use the DWT unit. Other test cases are similar, the only difference is the register configuration.

Helper functions are similar to Cortex-M33 project.

Arm CoreLink SSE-200!

The Memory Protection Controller (MPC) acts as security gate for AXI transactions that target a memory interface. The security checks operate on block or page level, and are programmable by using the APB slave interface. If a security violation occurs, the MPC generates an interrupt. The cfg_init_value of each MPC is tied to 0 so that at boot, the SRAM is Secure only. Software must change or restore the settings in the MPC to release memory for Non-secure world use.

These PPCs do not have their own software accessible programming interface. Instead, control of this PPC resides in the Secure Privilege Control Block and Non-secure Privilege Control Block.

While IDAU is an hardware unit that sits outside the processor, the SAU is software programmable Unit that sits inside the processor. (http://www.vlsiip.com/socsec/sau.html).

IDAU can set the memory alternates between Secure and Non-secure regions on 256Mbyte regions, with only a few address areas that are exempted from security mapping because they are related to debug functionality. To provide memory blocks and peripherals that can be mapped either as Secure or Non-secure using software, several address regions are aliased.

If any region of the memory is defined as 'secure' by either the IDAU or the SAU, it will be treated as secure.