CN117992949A - Sandbox system of multi-core embedded system based on ARMv7-M architecture - Google Patents

Abstract

The invention discloses a sandbox system of a multi-core embedded system based on an ARMv7-M architecture, which comprises: a compiler module, a reference monitor module; the capability of writing the core A into the core B of the multi-core embedded system is limited; the compiler module inserts an environment initialization code before the main function of the A core, replaces a conventional storage instruction in the unsafe code to be a non-privileged storage instruction, generates an initial program image, generates an MPU configuration strategy in running according to the initial program image, and outputs a final program image after checking the unsafe instruction; the reference monitor module is used for limiting the memory accessible by unsafe codes by utilizing the MPU hardware characteristic of the ARMv7-M architecture during operation. The invention realizes high-efficiency inter-core isolation based on the existing hardware, can be applied to a multi-core embedded system, improves the safety and has little influence on the system performance.

Description

Sandbox system of multi-core embedded system based on ARMv7-M architecture

Technical Field

The invention relates to the field of information security, in particular to a sandbox system of a multi-core embedded system based on an ARMv7-M architecture.

Background

In recent years, the big. LITTLE architecture has been widely used in the design of mobile device CPUs. The heterogeneous design combines a slow but power-saving microcontroller core (LITTLE core) with a fast but power-consuming microcontroller core (big core) to adapt to dynamic computing demands with lower power consumption. Many multi-core embedded systems employ this design because of the extended battery life.

However, this heterogeneous architecture also presents new security challenges due to the sharing of resources between the large and small cores. Specifically, memory and peripherals are shared between cores. If a software stack on one side of the core (e.g., a LITTLE core, which typically interacts with external inputs) has a vulnerability, an attacker may first exploit the vulnerability on one side and then mediate it to further invade the other side (e.g., a big core). Furthermore, for performance reasons, embedded systems typically do not consider rights separation, but instead run the entire firmware at the privileged level, exacerbating this problem. Therefore, isolation must be implemented between the large and small cores.

Software fault isolation (Software Fault Isolation, hereinafter SFI) is a mechanism for building logical protection domains through software instrumentation and hardware-assisted methods. Because pure software SFI systems typically rely on heavyweight code instrumentation or secure programming languages, the performance overhead is large and compatibility issues are significant. On the other hand, the hardware assistance scheme uses hardware primitives to realize protection, so that the efficiency is higher, and more attention is paid.

The classical approach to hardware-assisted SFI is to limit memory access of untrusted software using a memory protection unit (Memory Protection Unit, MPU). In existing memory isolation schemes, memory isolation is achieved by privilege separation, which downgrades most untrusted code to non-privileged level execution. Any modification to the system configuration by non-privileged code will be captured and checked by the trusted privilege reference monitor. However, some security sensitive instructions that modify the state of the system must run at the privilege level. To protect them from misuse by an attacker to break isolation, additional measures such as complex code detection and CFI (control flow integrity ) need to be deployed.

While effective, one drawback of the separation of permissions is that both reads and writes to the system configuration by non-privileged code are captured, whereas in most SFI cases we only want to capture and check write operations. Additional read access trapping (more frequent than write access) can result in significant performance overhead, thereby impeding deployment of hardware-assisted SFIs.

Disclosure of Invention

Aiming at the defects of the prior art, the invention provides a sandbox system of a multi-core embedded system based on an ARMv7-M architecture, and the invention can isolate firmware running on the ARMv7-M architecture core without depending on complete authority separation; ARMv7-M is one of ARM processor architectures, mainly applied to embedded systems.

The specific technical scheme is as follows:

A sandbox system for a multi-core embedded system based on an ARMv7-M architecture, comprising: a compiler module, a reference monitor module; the multi-core embedded system comprises an A core and a B core, and for the A core which is intended to write data into the B core, the capability of the A core for random writing is limited by the sandbox system;

The compiler module is used for inserting environment initialization codes before the main function of the A core and replacing conventional storage instructions in unsafe codes into non-privileged storage instructions, wherein the unsafe codes are codes for realizing functions of the A core; then generating an initial program image, generating an MPU configuration strategy during operation according to the initial program image, regenerating an intermediate program image, and checking whether unsafe instructions exist in the intermediate program image, wherein the unsafe instructions comprise conventional storage instructions and system instructions capable of modifying FAULTMASK registers; if yes, reporting an error, and starting execution after the generation of the initial program image is finished after the repair is completed; if not, outputting to obtain a final program image; the MPU configuration strategy sets the memory where the code section of the reference monitor module is located as read-only non-executable, and sets the memory where the data section and the stack are located as read-only;

The reference monitor module is used for limiting the memory accessible by unsafe codes by utilizing the MPU hardware characteristics of the ARMv7-M architecture during operation, and is realized by the following submodules:

The environment initialization submodule: starting the abnormal processing capacity of the reference monitor module, setting an MPU according to an MPU configuration strategy, and activating; the environment initialization submodule is executed before other submodules;

Non-privileged store instruction emulation submodule: analyzing a private peripheral bus with access privileges to trigger a non-privileged storage instruction with bus errors to obtain a target address to be written and a value to be written, checking whether the target address is safe and sensitive, if so, checking whether the value to be written is allowed, and if not, reporting errors; otherwise, simulating writing of the target address;

The external device dynamic activation submodule: analyzing a non-privileged storage instruction of the access peripheral to obtain a target address to be written in, identifying the peripheral corresponding to the target address, and reporting an error if no corresponding peripheral exists; otherwise, updating MPU configuration strategy to allow writing operation to be executed to the peripheral;

DMA security agent sub-module: analyzing a non-privileged storage instruction of the access DMA controller to obtain a target address to be written and a value to be written, identifying the DMA controller and the DMA channel corresponding to the target address, and if the target address is not available, reporting an error; otherwise, checking whether the current DMA channel is running or is about to run, if so, checking the corresponding DMA channel configuration to ensure that the A core data cannot be written into the protected memory area; otherwise, reporting error;

task switching sub-module: when switching tasks, checking whether the MPU configuration of the call-in task meets the following conditions: code segments, data segments and stacks of the A core and the B core are not covered, and code segments, data segments and stacks of the reference monitor are not covered, and code execution authority is prohibited.

Further, traversing unsafe codes byte by using a code scanner, and searching unsafe instructions which possibly occur; the conventional store instruction is replaced with a non-privileged store instruction using static program analysis techniques.

Further, in the compiler module, for the STREX instruction without the non-privileged version, a packing function is provided for it manually, and in the packing function, the target address and the written value of the STREX instruction are checked.

Further, the MPU supports 7 regions, and a specific configuration strategy is as follows:

① Region 0 sets the global address space to be read-only non-executable;

② Region 1-3 is reserved for external device dynamic activation; if the unsafe code uses FreeRTOS-MPU operation system, region 3 is used to read and write FreeRTOS task stack obtained by unsafe code distribution;

③ Region 4 sets the code segment of the A core to be read-only executable;

④ Region 5 sets the code segment of the A core to be readable and writable and non-executable;

⑤ Region 6 sets the flash memory used by core B inaccessible;

⑥ Region 7 sets that static random access memory used by core B is not accessible.

Further, in the environment initialization sub-module, the activated operation is as follows: setting MPU_CTRL.HFNMIENA bit to 0 and MPU_CTRL.ENABLE bit to 1 jumps execution flow to the unsafe code and executes at the privileged level.

Further, in the reference monitor module, a safety door is arranged for controlling whether the reference monitor module can operate and modify data; by entering a secure gate, the restriction on the reference monitor module code execution and data writing is released, thereby allowing its own code to be executed and its data to be modified; protection of the reference monitor module code and data is restored by exiting the security gate.

Further, the access safety door specifically comprises: setting HFNMIENA bits of an MPU control register to 0, so that the MPU can be automatically turned off when the current execution priority value is lifted to-1; when the MPU is turned off, the memory authority of the whole physical address space depends on the default memory mapping, and at the moment, the code of the reference monitor can be normally executed, and the data of the code can be normally read and written;

The exit safety door specifically comprises: when the current execution priority value is restored from-1 to other non-negative values, the hardware MPU feature is automatically restored to an enabled state, at which point protection of the reference monitor module code and data is restored.

The beneficial effects of the invention are as follows:

the invention uses the existing MPU hardware characteristic on the ARMv7-M architecture to limit the resource access of each core in the multi-core embedded system based on the ARMv7-M architecture. Based on the existing hardware, the method realizes high-efficiency inter-core isolation, can be applied to a multi-core embedded system, improves safety, and has little influence on system performance.

Drawings

FIG. 1 is a schematic diagram of a compiler module of a sandbox system of a multi-core embedded system based on an ARMv7-M architecture in an embodiment of the invention.

FIG. 2 is a schematic diagram of MPU configuration strategy of a sandbox system of a multi-core embedded system based on ARMv7-M architecture in an embodiment of the present invention, where (a) is a Cortex-M4 core memory view, (b) is a schematic diagram of 5 regions (0, 4-7) of a predefined MPU, and (c) is a default memory map.

FIG. 3 is a schematic diagram of a reference monitor module of a sandbox system of a multi-core embedded system based on the ARMv7-M architecture in an embodiment of the invention.

In fig. 2, P is PRIVILEGED for short, which represents a privilege level; u is Unprivileged for short, which represents a non-privilege level; RO is short for Read-Only, representing Read-Only; RW is short for Read & Write, and represents readable and writable; NA is the abbreviation of No Access, which indicates inaccessible; NX is short for Non-eXecutable and indicates Non-executable.

Detailed Description

The objects and effects of the present invention will become more apparent from the following detailed description of the preferred embodiments and the accompanying drawings, in which the present invention is further described in detail. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.

A sandbox system for a multi-core embedded system based on an ARMv7-M architecture, comprising: a compiler module, a reference monitor module; it should be noted that, in this embodiment, for convenience of explanation, it is assumed that the littale core (i.e., the a core) is not trusted. For the a core, which intends to write data to the B core, the ability of the a core to write arbitrarily is limited by the sandboxed system.

As shown in fig. 1, the compiler module is used for the operation before the operation of the multi-core embedded system, and sequentially realizes the following functions:

(1) The context initialization code is inserted before the main function of the a-core.

(2) The normal storage instruction in the unsafe code is replaced by a non-privileged storage instruction by using a static program analysis technology, and the unsafe code is the code which realizes the function of the A core. In this embodiment, the code scanner is used to traverse the unsafe code byte by byte, looking for possible unsafe instructions, including conventional store instructions and system instructions that can modify FAULTMASK registers. Replacing the conventional storage instruction with a non-privileged storage instruction by using a static program analysis technology, and reporting to a developer to manually delete if a 'system instruction capable of modifying FAULTMASK registers' appears; for STREX instructions without non-privileged versions, a wrapper function is provided for it manually, in which the target address and written value of the STREX instruction are checked, this checking process being implemented by a reference monitor module.

The encapsulation function of the STREX instruction is as follows:

uint32_t_strex(uint32_t value,volatile void*addr){

__asm volatile(

"STREX％0,％2,％1":

"＝&r"(ret),"＝Q"(*addr):"r"(value))；

return ret；

uint32_t strex(uint32_t value,volatile void*addr){

__asm volatile("CPSID f")；

if(check_addr(addr)＝＝True){

ret＝_strex(value,addr)；

}

else

ret＝1；

__asm volatile("CPSIE f")；

return ret；

}

The encapsulation function first executes a CPSIDF instruction (a security gate entry) to enter the security gate, and then checks the target address to be written by the STREX instruction; the security gate is used to control whether the reference monitor module code can be executed and data written. If the target address is safe, executing the STREX instruction; if not, reporting error. Finally, the exit gate is exited by execution of CPSIE f instructions (gate exit). The packaging function realizes the inspection of the target address to be written in by the STREX instruction through fast entering and exiting the safety gate, and avoids simulating the behavior of the instruction.

(3) Generating an initial program image, generating an MPU configuration strategy when running according to the initial program image as unsafe codes, regenerating an intermediate program image, checking whether unsafe instructions exist in the intermediate program image, reporting errors if so, and executing from the MPU configuration strategy when running according to the initial program image after user repairing is completed; if not, the program image generation is completed, and the final program image is obtained. The final program image contains a reference monitor whose code and unsafe code are located in different sections, as are the data of the reference monitor and the data of the unsafe code.

As shown in fig. 2, the MPU is configured to support 7 regions in this embodiment, and a specific configuration policy is as follows:

① Region 0 sets the global address space to be read-only non-executable.

② Regions 1-3 are reserved for external device dynamic activation. If the unsafe code uses FreeRTOS-MPU operating system, region 3 is used to read and write the FreeRTOS task stack allocated by the unsafe code.

③ Region 4 sets the code segment of the a core to read-only executable.

④ Region 5 sets the code segment of the a core to be read-write non-executable.

⑤ Region 6 sets the Flash (Flash) used by the B core inaccessible.

⑥ Region 7 sets the SRAM (Static random-access memory) used by the B core inaccessible.

Meanwhile, the memory in which the code segment of the MPU configuration strategy setting reference monitor module is located is read-only and can not be executed, and the memory in which the data segment and the stack are located is set read-only, so that malicious modification of the A core is avoided, and safety is improved.

As shown in fig. 3, the reference monitor module is configured to limit the memory that can be accessed by the unsafe code by utilizing the MPU hardware characteristics of the ARMv7-M architecture during operation, and is specifically implemented by the following submodules: the system comprises an environment initialization sub-module, a non-privileged storage instruction simulation sub-module, an external device dynamic activation sub-module, a DMA (Direct Memory Access ) security agent sub-module and a task switching sub-module. Wherein the environment initialization submodule is executed before the other submodules.

The environment initialization submodule has the following functions: and activating the abnormal processing capacity of the reference monitor module, setting the MPU according to the MPU configuration strategy, and activating. The operation of activation is: setting MPU_CTRL.HFNMIENA bit to 0 and MPU_CTRL.ENABLE bit to 1 jumps execution flow to the unsafe code and executes at the privileged level.

The role of the non-privileged store instruction emulation submodule is: analyzing a private peripheral bus of access privileges to trigger a non-privileged storage instruction of bus errors (under privilege level, using the non-privileged storage instruction to write a register on the private peripheral bus and trigger the bus errors) to obtain a target address to be written by the non-privileged storage instruction and a value to be written, checking whether the target address is safe and sensitive, and if not, simulating writing to the target address; if so, checking whether the value to be written is allowed or not, if not, reporting an error, and if so, simulating writing to the target address. Instruction emulation emulates non-privileged store instructions using a bus error handling function.

The peripheral dynamic activation submodule has the functions that: analyzing a non-privileged storage instruction of an access peripheral to obtain a target address to be written in by the non-privileged storage instruction, identifying the peripheral corresponding to the target address, and reporting an error if no corresponding peripheral exists; and otherwise updating the MPU configuration strategy to allow the writing operation to be performed on the peripheral.

The DMA security agent sub-module has the functions of: analyzing a non-privileged storage instruction accessing the DMA controller to obtain a target address to be written in and a value to be written in of the non-privileged storage instruction, identifying the DMA controller and the DMA channel corresponding to the target address, and reporting an error if the corresponding DMA controller and DMA channel do not exist; otherwise, checking whether the current DMA channel is running or is about to run, if so, checking the corresponding DMA channel configuration to ensure that the protected memory area is not written; if not, reporting error; the protected memory area is the memory area which is not allowed to be written by the A core in the MPU configuration strategy.

The functions of the peripheral dynamic activation sub-module and the DMA security agent sub-module are realized by using a memory management error processing function.

The task switching sub-module has the functions of: at the time of task switching (including at FreeRTOS the task switching), it is checked whether the MPU configuration calling the task satisfies the following condition: code segments, data segments, and stacks of the A core and the B core are not covered (i.e., do not coincide with the predefined MPU Region 4-7 address range), and code segments, data segments, and stacks of the reference monitor are not covered, disabling code execution authority. If the MPU configuration of the tuning task meets the conditions, updating the MPU strategy of the tuning task to the MPU; otherwise, reporting the error.

Both the reference monitor module and the unsafe code operate in privileged mode, and when an application program executes, the code of the reference monitor module cannot be executed and the data cannot be modified. The reference monitor module removes the restriction of code execution and data writing of the reference monitor module by entering a security gate, thereby allowing the execution of its own code and the modification of its data; protection of the reference monitor module code and data is restored by exiting the security gate. The implementation principle of the safety door is as follows:

(1) Entering a safety door: setting HFNMIENA bits of an MPU control register to 0, so that the MPU can be automatically turned off when the current execution priority value is lifted to-1; when the MPU is turned off, the memory authority of the whole physical address space is determined by the default memory map. The memory permissions specified by the default memory map are more extensive, so that code of the reference monitor can be normally executed, and data thereof can be normally read and written.

(2) Exit the safety door: when the current execution priority value returns from-1 to other non-negative values, the hardware MPU feature is automatically restored to an enabled state.

The design of the safety door is as follows:

void Exception_Handler(void){

__asm volatile(

entry_gate:

CPSID f

Save{R0-R12,SP,LR,PC,xPSR}

Switch Stack

handler_main:

bl Exception_Handler_Main

exit_gate:

Switch Stack

Restore{R0-R12,SP,LR,PC,xPSR}

CPSIE f

)；

}

At the security gate entry, the CPSIFF instruction is first executed into the security gate, then the context is saved, the stack pointer is switched to the stack used by the reference monitor, and finally the reference monitor sub-module is executed. When the reference monitor submodule execution ends, the exit of the security gate from the security gate exit is required. At the exit of the security gate, the stack pointer is first switched back to the stack used by the unsafe code, the saved context is restored, and finally the CPSIE f instruction is executed to exit the security gate. The security gate design ensures secure execution of the reference monitor submodule itself, avoiding misuse of the reference monitor code by unsafe code.

It will be appreciated by persons skilled in the art that the foregoing description is a preferred embodiment of the invention, and is not intended to limit the invention, but rather to limit the invention to the specific embodiments described, and that modifications may be made to the technical solutions described in the foregoing embodiments, or equivalents may be substituted for elements thereof, for the purposes of those skilled in the art. Modifications, equivalents, and alternatives falling within the spirit and principles of the invention are intended to be included within the scope of the invention.

Claims (7)

1. A sandbox system of a multi-core embedded system based on an ARMv7-M architecture, comprising: a compiler module, a reference monitor module; the multi-core embedded system comprises an A core and a B core, and for the A core which is intended to write data into the B core, the capability of the A core for random writing is limited by the sandbox system;

The compiler module is used for inserting environment initialization codes before the main function of the A core and replacing conventional storage instructions in unsafe codes into non-privileged storage instructions, wherein the unsafe codes are codes for realizing functions of the A core; then generating an initial program image, generating an MPU configuration strategy during operation according to the initial program image, regenerating an intermediate program image, and checking whether unsafe instructions exist in the intermediate program image, wherein the unsafe instructions comprise conventional storage instructions and system instructions capable of modifying FAULTMASK registers; if yes, reporting an error, and starting execution after the generation of the initial program image is finished after the repair is completed; if not, outputting to obtain a final program image; the MPU configuration strategy sets the memory where the code section of the reference monitor module is located as read-only non-executable, and sets the memory where the data section and the stack are located as read-only;

The reference monitor module is used for limiting the memory accessible by unsafe codes by utilizing the MPU hardware characteristics of the ARMv7-M architecture during operation, and is realized by the following submodules:

The environment initialization submodule: starting the abnormal processing capacity of the reference monitor module, setting an MPU according to an MPU configuration strategy, and activating; the environment initialization submodule is executed before other submodules;

Non-privileged store instruction emulation submodule: analyzing a private peripheral bus with access privileges to trigger a non-privileged storage instruction with bus errors to obtain a target address to be written and a value to be written, checking whether the target address is safe and sensitive, if so, checking whether the value to be written is allowed, and if not, reporting errors; otherwise, simulating writing of the target address;

The external device dynamic activation submodule: analyzing a non-privileged storage instruction of the access peripheral to obtain a target address to be written in, identifying the peripheral corresponding to the target address, and reporting an error if no corresponding peripheral exists; otherwise, updating MPU configuration strategy to allow writing operation to be executed to the peripheral;

DMA security agent sub-module: analyzing a non-privileged storage instruction of the access DMA controller to obtain a target address to be written and a value to be written, identifying the DMA controller and the DMA channel corresponding to the target address, and if the target address is not available, reporting an error; otherwise, checking whether the current DMA channel is running or is about to run, if so, checking the corresponding DMA channel configuration to ensure that the A core data cannot be written into the protected memory area; otherwise, reporting error;

task switching sub-module: when switching tasks, checking whether the MPU configuration of the call-in task meets the following conditions: code segments, data segments and stacks of the A core and the B core are not covered, and code segments, data segments and stacks of the reference monitor are not covered, and code execution authority is prohibited.

2. The sand box system of the multi-core embedded system based on the ARMv7-M architecture as claimed in claim 1, wherein the code scanner is used for traversing unsafe codes byte by byte to find possible unsafe instructions; the conventional store instruction is replaced with a non-privileged store instruction using static program analysis techniques.

3. The ARMv7-M architecture-based sandboxed system of the multi-core embedded system of claim 1, wherein the compiler module, for a STREX instruction without a non-privileged version, manually provides it with a packing function in which the target address and written value of the STREX instruction are checked.

4. The sand box system of a multi-core embedded system based on an ARMv7-M architecture of claim 1, wherein the MPU supports 7 regions, and a specific configuration policy is as follows:

① Region 0 sets the global address space to be read-only non-executable;

② Region 1-3 is reserved for external device dynamic activation; if the unsafe code uses FreeRTOS-MPU operation system, region 3 is used to read and write FreeRTOS task stack obtained by unsafe code distribution;

③ Region 4 sets the code segment of the A core to be read-only executable;

④ Region 5 sets the code segment of the A core to be readable and writable and non-executable;

⑤ Region 6 sets the flash memory used by core B inaccessible;

⑥ Region 7 sets that static random access memory used by core B is not accessible.

5. The ARMv7-M architecture-based sandboxed system of the multi-core embedded system of claim 1, wherein in the environment initialization sub-module, the operations of activating are: setting MPU_CTRL.HFNMIENA bit to 0 and MPU_CTRL.ENABLE bit to 1 jumps execution flow to the unsafe code and executes at the privileged level.

6. The sand box system of the multi-core embedded system based on the ARMv7-M architecture as claimed in claim 1, wherein a safety door is arranged in the reference monitor module for controlling whether the reference monitor module can run and modify data; by entering a secure gate, the restriction on the reference monitor module code execution and data writing is released, thereby allowing its own code to be executed and its data to be modified; protection of the reference monitor module code and data is restored by exiting the security gate.

7. The sand box system of the multi-core embedded system based on the ARMv7-M architecture as claimed in claim 6, wherein the entry security door is specifically: setting HFNMIENA bits of an MPU control register to 0, so that the MPU can be automatically turned off when the current execution priority value is lifted to-1; when the MPU is turned off, the memory authority of the whole physical address space depends on the default memory mapping, and at the moment, the code of the reference monitor can be normally executed, and the data of the code can be normally read and written;

The exit safety door specifically comprises: when the current execution priority value is restored from-1 to other non-negative values, the hardware MPU feature is automatically restored to an enabled state, at which point protection of the reference monitor module code and data is restored.