CToMP: A Cycle-task-oriented Memory Protection Scheme for Unmanned Systems

As for power consumption, hardware platforms of unmanned systems are still dominated by low-cost MCUs, such as STM32 series based on the ARM Cortex-M architecture. To ensure the availability of systems, the development of unmanned systems focuses more on realizing more applications with limited software and hardware resources rather than security protection that may take up more resources. However, these low-cost MCUs are also designed with security features, which have not been taken seriously. We will briefly introduce these features.

In MCAs attackers use memory vulnerabilities to inject Shellcode into the stack to achieve various malicious operations. As shown in Figure 4, Shellcode can be executed in two ways. Type I involves overwriting the return address in the stack to the existing function address in memory so that the device can perform some operations that are not allowed or illogical; it is called return2libc. Type II involves overwriting the return address in the stack with the starting address of Shellcode to execute the malicious behavior customized by the attacker. We name it return2shellcode. Additionally, MCAs for embedded unmanned systems are subdivided into several cases in Table 2 according to different Shellcode attack targets. Notably, as a variant of return2libc attack, the ROP attack [22, 23] has been widely discussed on x86 architecture systems. This attack executes instruction sequences, called gadgets, in the existing code area through the stack overflow vulnerability, and each gadget ends with a ret instruction. By chaining these gadgets together with Shellcode, an attacker can modify registers or some memory data. In the unmanned system scenario, the ROP attack is similar to attack case ② in Table 2.

Because of hardware and performance limitations, the existing embedded development platforms do not have memory isolation or address randomization and other security protection measures that can effectively avoid MCAs. Therefore, we believe that MCAs are ubiquitous in embedded unmanned systems. We assume the attackers have the following abilities to find and exploit memory vulnerabilities to perform attacks.

• •

  Attackers can use Fuzzing [24, 25, 26] and other testing methods to discover memory vulnerabilities, such as stack overflow in the communication protocol encoding/decoding of the system remote control.

• •

  Attackers can use static analysis tools  [27, 28, 29, 30] to reverse the firmware in embedded hardware and obtain the memory addresses of sensitive parameters, such as the PID parameters.

• •

  Attackers can discover which key registers are accessed during the sensor reading and writing process through firmware Re-Hosting [31, 32, 33, 34].

Because Shellcode must be injected from outside the system, the vulnerabilities that can be easily exploited by attackers lie in the user code interacting with the outside rather than in the kernel responsible for interrupt management, task scheduling and other internal features. After discovering the vulnerabilities, attackers write ShellCode and tamper with the return address of the stack frame to achieve MCAs. Because all codes in an MCU share the same physical memory, an attacker who launches an attack from the user code can modify key parameters in the memory by injecting malicious instructions. In addition to attackers, ordinary users may also modify key parameters in the kernel because of misoperation, such as setting unreasonable PID parameters through MAVLink commands [35], which can also have disastrous consequences.

At present, the most effective solution to MCAs is to implement memory isolation between the kernel space and user code, which limits the range that malicious code can access in memory [13, 14, 36, 18]. These relevant works achieve memory isolation by building a memory view for each task, just like running a task in a Sandbox, and we summarize them as task-oriented solutions. Task-oriented memory isolation requires configuring MPU registers for the next task after one task ends, which is called memory view switching. Since MPU registers are accessible only in privileged mode, memory view switching must enter an exception handler and switch mode while the task runs in unprivileged mode. We summarize two stages in memory view switching as follows:

First, before task application execution, the following steps are required:

• (1)

  The scheduler reads the task information list and decides which task must be executed next.

• (2)

  The system initializes the process stack required by the task code and switches the memory view to configure the memory regions that the task can access by MPU.

• (3)

  The system switches from the main stack to the process stack.

• (4)

  The system switches the execution level from privileged mode to unprivileged mode.

Second, to switch from unprivileged mode to privileged mode after task completion, the following steps are required:

• (1)

  The system enters SVC interrupt through a system call, and switches from unprivileged mode to privileged mode.

• (2)

  Then, the system switches the stack pointer from PSP to MSP.

Through experiments, we also sorted out the time spent in each step, as shown in Table  3. However, when we applied this task-oriented solution to Ardupilot, an open-source unmanned system firmware, efficiency problems emerged. In the search for the cause, we found that although the task scheduling of unmanned systems is uncertain and irregular in the traditional concept, we can use a cycle-based model to describe it. Unmanned systems perform a certain number of tasks during each cycle. We will describe this model in detail in §3.1. Since at least seven tasks need executing in one cycle in Ardupilot, it takes at least 154$\mu$sec for frequent memory view switching between tasks. Consequently, some low-priority tasks cannot obtain the time in a cycle to execute, which affects unmanned system availability. Therefore, we consider whether we can use MPU to manage the memory access range of a cycle, which is similar to putting all tasks in a cycle into a sandbox rather than putting one task into one sandbox. This approach reduces the frequency of memory view switching, thereby improving system efficiency.

However, we need to prevent attackers from attacking tasks in the same cycle. When we simultaneously manage several tasks in a cycle with MPU, tasks do not securely access the code and data from each other because they share the same region of memory. We determine the static loading of the code as the reason why embedded unmanned systems are vulnerable to MCAs. This attribute allows attackers to easily analyze the call stack and memory addresses and inject Shellcode to cause damage. Therefore, we hope to implement random memory allocation, which is not widely used in embedded unmanned systems because of the lack of the Memory Management Unit (MMU), and improve the difficulty of memory analysis, so as to achieve the purpose of protecting user code and data in the same cycle.

Unmanned systems encapsulate simple functions such as sensor reading/writing and actuator execution into multiple tasks, and realize more complex remote control or autonomous operations through the cooperation between tasks. In the traditional concept, the unmanned system, as a real-time system, requires each task to be completed at a certain time, and these tasks are triggered uncertainly by the external environment. For example, we cannot predict when the unmanned system will encounter an obstacle and change its trajectory. Table 4 summarizes the results of our research on various unmanned system firmware applicable to drones, rovers, and boats. However, we found that although the number of tasks in these firmware varies, they all rely on the real-time operating system (RTOS) to implement task scheduling. Further, the scheduling algorithms in these RTOSes are composed of preemptive scheduling and round robin. This means, in practical design, unmanned systems only need to implement three stages of functions—environment perception, behavior decision and action execution, which are supported by tasks within a specified time period to meet the real-time requirement, and we call this time period a cycle. As shown in Figure 6, we regularize seemingly uncertain and irregular task executions in unmanned systems with cycle-based modeling, thereby laying the foundation for our system design. In detail, $f_{m}$ in Figure 6 represents the cycle frequency, that is, how many cycles will be experienced in one second, and the longest available duration of one cycle is $1/f_{m}$ seconds. Then for task $i$, its frequency $f_{i}$ is determined by the average cycle interval (ACI) at which it can be scheduled:

For example, in an unmanned system with a cycle frequency of 400Hz, a task is executed every two cycles on average, then the frequency of this task is 200Hz. What’s more, each task is given a priority. In a cycle, high-priority tasks must be scheduled first, while low-priority tasks will use the remaining time as needed after the execution of high-priority tasks. This enables each task to meet its functional requirements as much as possible. Therefore, it can be obtained that the less time a cycle takes, the faster the cycle frequency becomes, and each task can be scheduled in a more timely manner, so the real-time requirement of the unmanned system is guaranteed. Conversely, if the single cycle time is long, the system reliability will be reduced.

The main goal of our system design is to prevent attackers from exploiting victim tasks with memory vulnerabilities to access kernel code or modify memory data. Specifically, our approach should be able to defend against each attack case in §2.2 effectively. As illustrated in Figure 6, in our system architecture, the code segment, data segment, and device address segment in the memory are separated by MPU into two environments: privileged mode and unprivileged mode. According to the assumptions in §2.2, as user code for all tasks is executed in unprivileged mode, the Shellcode injected by an attacker to exploit memory vulnerabilities usually occurs in unprivileged mode. Unlike relevant task-oriented approaches that require designing a memory view for each task and attack to defend against MCAs, our solution focuses on blocking two attack paths of Shellcode to secure the unmanned systems. We explain how this architecture meets the design goal G1 Security as follows.

First, for attack cases ③, ⑦, and ⑧, the data and registers in these attack objects should be configured and fixed in memory when the unmanned system is initialized. Therefore, we only need to configure these parameters and registers to be unmodifiable in unprivileged mode with MPU after they are set. They can be effectively protected from being accessed by the attacker’s Shellcode. At the same time, we configure the entire code segment to be non-writable with MPU, so that attack case ⑤ cannot overwrite the existing code with malicious instructions through Shellcode.

For attack case ④, ticks and last_run, these two count parameters are used for task scheduling, and they are changed in each cycle to ensure that the execution of each task can meet the functional requirements. Parameter ticks is the number of cycles that have passed, last_run is an array used to calculate the interval between the last executed cycle of each task and the current cycle. Therefore, we set the two parameters to be modifiable only in privileged mode. When the tasks of a cycle are executed, the system switches the execution level once, and then updates these two parameters after entering privileged mode, which can satisfy the task scheduling and parameter security.

Finally, for some code and data that must share the memory with other tasks, such as reading remote control variables from registers that can only run in unprivileged mode (attack case ⑥), we design another solution to protect their security. By analyzing the execution condition of return2shellcode, we found that the attacker needs to obtain the starting address of injected Shellcode to jump to the malicious code execution area by tampering with the return address in the stack. Due to the static loading code of MCUs, it is easy for an attacker to analyze the required memory address and implement malicious behavior. However, we noticed that using the two instructions __set_PSP and __set_CONTROL(SP_PROCESS) can specify an area in memory as the process stack used by tasks. If we randomize the stack in each cycle, it will be much more difficult for an attacker to analyze the starting address of Shellcode, which can effectively prevent the execution of Shellcode. Therefore, we design a memory pool in unprivileged mode to dynamically allocate a random address area for the stack used in each cycle.

In summary, CToMP can resist all attack cases and meet the design goal G1 Security. At the same time, different from task-oriented solutions, we manage the memory access range of tasks in a cycle as a whole, so that the MPU configuration and execution level switching do not need to be performed between tasks, but only before the start of a cycle, so as to satisfy the design goal G2 Efficiency. In addition, since MPU in MCUs can protect up to 16 memory regions, it is difficult for solutions that only rely on MPU to play a protective role when the functions of unmanned systems are gradually complex. Our solution can effectively prevent the execution of Shellcode by randomizing the process stack, and is not limited by the number of MPU-protected memory regions and other hardware resources, which meets the design goal G3 Extensibility. What’s more, we only add a memory pool area into the system architecture to achieve dynamic memory allocation, and we will describe how the memory pool satisfies the design goal G4 Low Footprint in §3.3. Last but not least, MPU, execution levels and the process stack are features supported by most unmanned system MCUs, so our system architecture can be easily adapted to other unmanned system firmware and RTOSes, and our design realizes the G5 Generality.

Unfortunately, due to the lack of MMU support, MCUs for unmanned systems do not support dynamic memory allocation, or can only allocate memory blocks with fixed addresses, which does not meet our needs for randomizing the process stack. For example, only three fixed regions are provided for memory allocation to choose from in ChibiOS, which supports the unmanned system firmware Ardupilot. In order to be compatible with the existing memory allocation solutions in unmanned systems, we designate an area in memory as a memory pool. We use the following structure array $R=\{r_{0},r_{1},\dots,r_{n}\}$ to denote the usage of the memory pool.

In this structure, we define a pointer to the allocated memory region, the start addresses of the region and the allocation size. At the same time, we also need to specify the maximum number of memory regions that can be allocated by defining the value of MAX_ALLOCATE_NUM. Three functions are designed to allocate, re-allocate and free memory:

As described in Algorithm 1, mem_alloc uses the True Random Number Generator (TRNG) [37] supported by ARM Cortex-M series MCUs to generate a start address of the memory area to be allocated. Then, when the number of allocated regions does not reach the maximum setting, the allocator needs to traverse all memory regions in the structure array allocated_region to check whether there is a conflict between the to-be-allocated region and the allocated regions. If there is no conflict, the allocator should save the region information into the structure array. Otherwise, it will find the allocatable region again by mem_realloc. To free the allocated memory, it just needs to call mem_free to delete the information of the pointer in the structure array.

In order to measure the space occupancy of the memory pool, we summarize the stack and buffers that use memory allocation and the size of regions they require in Table 5. It can be seen only five buffers and one stack need to dynamically allocate memory; the value of MAX_ALLOCATE_NUM should be set to 6, which means that the space occupied by the structure array allocated_region is 72 bytes. At the same time, the total memory space required for these buffers and the process stack is 1712 bytes. In order to ensure the randomness of the process stack space address, we set the size of the memory pool to 5632 bytes, which is about three times the size of the total required space. Since most MCUs have 1MB-2MB of Flash ROM and 192KB-512KB of SRAM, the memory pool we designed has a very small footprint and can meet the design goal G4.

On the other hand, in order to secure the memory allocation, we need to configure the three functions and the struct array allocated_region to be accessible only in privileged mode with MPU. Only the memory pool can be accessed by tasks in unprivileged mode. Due to the real-time requirement of unmanned systems, the data in these buffers that need to dynamically allocate memory are only valid for one cycle; that is, they will not be available in the next cycle. So we allocate memory for them at the beginning of a cycle and release them at the end of the cycle, which can effectively meet their usage requirements. This also means that we do not need to perform frequent execution level switching in order to securely allocate memory by MPU. As illustrated in Figure 7, we implement a secure process stack to resist Shellcode execution.

Our approach works upon cycle-based task modeling, where three stages of functions (i.e., environment perception, behavior decision, and action execution in one cycle) are embedded within. The workflow of CToMP corresponds to the three stages of functions in one cycle.

First, use MPU to configure hardware and software resources that can be accessed in one cycle. Then, a region is allocated in the memory pool for tasks of this cycle as a secure process stack. At the same time, we also need to allocate regions in the memory pool for other buffers. Next, we use the __set_CONTROL instruction to make the stack pointer point to the secure process stack and switch the execution level to unprivileged mode.

In unprivileged mode, each task is scheduled on demand based on the priority and two soft timing parameters (ticks and last_run) that are read-only in this mode. At this stage, the unmanned system uses various sensors and communication equipment to complete the perception of the surrounding environment and its own state and receive control commands.

After tasks in a cycle are executed, the unmanned system needs to switch back to privileged mode to call some key functions protected by MPU, implement behavior decision and action execution, and allocate memory resources for the next cycle. Therefore, the user code is required to call the SVC instruction into the exception handler. In exception handling, switch the execution level back to privileged mode, and replace the running stack with the main stack after exiting the exception. In addition, we can also update soft timing parameters in this mode. We describe the above workflow with Figure 8.

According to the unmanned system model in §3.1, we conclude that one of the ways to ensure the real-time performance of unmanned systems is to shorten the running time of a cycle. Therefore, we clarify the advantages of CToMP in the design goal G2 Efficiency by analyzing the computation cost of CToMP in one cycle and comparing it with the task-oriented approach. We assume that $n$ tasks need to be executed in one cycle, and the task-oriented memory protection method uses MPU to limit $m_{i}$ accessible areas for each task to prevent damage attacks caused by memory leaks. At the same time, since the tasks are all executed in unprivileged mode, and MPU can only be configured in privileged mode, each time a task is executed, it needs to go through the mode switch twice to configure MPU and stack for the next task before return to unprivileged mode. Therefore, in a task-oriented manner, the computation cost in one cycle is:

In Eq. (2), $T_{MPU}$ denotes the time cost for MPU to configure a memory area, $T_{Stack}$ denotes the time cost of the process stack initialization, $T_{SVC}$ is the time consumed in one SVC call, and $T_{switch}$ is the time cost of one mode switch. These indicators’ values can be found in Table 3.

From the workflow of CToMP in Figure 8, it can be seen that since we regard all tasks in one cycle as a whole, CToMP mode only switches twice in one cycle. That is, switching to the unprivileged mode when entering a new cycle. After the cycle ends, switching to privileged mode to process sensitive data with an SVC call. What’s more, due to only protecting key code and data, the memory regions configured by MPU pre-cycle are also fewer. We suppose these memory regions are $z$ blocks. The computation cost of CToMP is as follows:

By comparing Eq. (2) and (3), we can obtain that the computation cost of CToMP in one cycle is much smaller than that of the task-oriented scheme, so CToMP meets design goal G2. More discussion on performance evaluation will be detailed in §4.2.2.

We implement CToMP on CUAV V5+, a typical unmanned aerial vehicle that is full compatibility with the Pixhawk project FMUv5 design standard. CUAV V5+ is equipped with an ARM 32-bit Cortex-M7 processor, a 512KB SRAM and a 2MB Flash memory where the code and data are stored. Similar to most unmanned systems designed based on the Pixhawk standard, CUAV V5+ supports the open source firmware, Ardupilot, which uses ChibiOS as the real-time operating system. We also chose an open source drone, Crazyflie, which is equipped with an ARM 32-bit Cortex-M4 CPU, a 196KB SRAM and a 1MB Flash memory and uses FreeRTOS as the operating system. We use Crazyflie as a supplementary experiment to verify the generality of our solution. Figure 9 shows our experiment platforms and a simple ground control station (GCS) to record the flight status of our UAVs so that we can analyze the experimental results.

To illustrate the generality of CToMP , we validate it on another unmanned system, Crazyflie. Since Crzayflie uses the relatively low-end STM32F405 as the MCU, it needs more efficient security functions. There are two main missions in Crazyflie, STABILIZER and SENSORS. STABILIZER is mainly responsible for the attitude control of drones, while SENSORS is used to collect data from sensors such as gyroscopes and accelerometers. At the same time, there is also a Crazy RealTime Protocol (CRTP) service for data communication with the control side.

Similar to Ardupilot, attackers can exploit vulnerabilities¹¹1https://forum.bitcraze.io/viewtopic.php?t=2063²²2https://forum.bitcraze.io/viewtopic.php?t=4923 in the firmware to inject Shellcode. Therefore, in CToMP , we use MPU to put STABILIZER into privileged mode, which is isolated from other user codes that can interact with the outside world. This can effectively protect the attitude control of drones from being interfered with the malicious code. Unlike Ardupilot, where multiple tasks can use the same process stack, the operating system FreeRTOS in Crazyflie uses xTaskCreate to allocate a fixed stack for each task in RAM, and makes the PSP point to the corresponding stack when the task is scheduled, as illustrated in Figure 14. This eliminates the need to build a memory pool, but only needs to randomly change the stack address of each task in RAM in each cycle. We also tested the effect of CToMP on the real-time performance of Crazyflie, as shown in Figure 14. In the experiments, the execution frequency of Crazyflie tasks was not affected by CToMP .