The microcomputer cluster is a group of connected microcomputers that work together to perform as a single system. Unlike high-performance computer clusters, microcomputer clusters are designed to provide reliable and efficient services for safety-critical embedded systems, which usually require low SWaP (Size, Weight, and Power) because of the high stability and cost control requirements. Considering that safety-critical systems have strict real-time constraints (i.e., deadline constraints) and resource constraints, each microcomputer usually needs to run a Real-Time Operating System (RTOS) instead of Linux to achieve precise scheduling and control, and a high-speed real-time network such as Time-Triggered Ethernet (TTE) is required for intra-cluster communication. In microcomputer clusters, a load imbalance between microcomputers usually leads to system instability, and a lightweight application distribution framework automatically migrates applications among microcomputers, thereby breaking resource isolation and improving resource utilization. However, mainstream application distribution frameworks, such as Kubernetes (K8s), MicroK8s, and K3s, can be applied neither to RTOS nor to TTE. In this study, we design a lightweight application distribution framework with automated and real-time computing and communication (ARC2). ARC2 monitors the microcomputer cluster resource state in real-time and introduces a resource hierarchical pooling method to utilize cluster resources flexibly. It employs TTE for application distribution combined with a real-time scheduling strategy, achieving low end-to-end latency and load balancing. It simplifies the existing application distribution framework and introduces a low-complexity cluster management logic to achieve low resource overhead. We conduct experimental evaluations on a heterogeneous platform. The results show that: (1) the load imbalance is reduced by at least 59.81% compared to the original system; (2) the deviation in real-time monitoring traffic is reduced by an average of 56.7 ms, with the application distribution success rate reaching 100% and an average distribution time of 393.0 ms; and (3) the CPU, memory, and bandwidth overhead are 9%, 3 MB, and 0.104 Mb/s, respectively.

Control flow is the execution order of individual statements, instructions, or function calls within an imperative program. Malicious operation of control flow (e.g., tampering with normal function addresses) leads to severe consequences such as data leakage and system crash. Control Flow Integrity (CFI) is a defense restricting the execution order of program within Control Flow Graph (CFG). IndexHooks is an existing CFI solution designed against forward function calls tampering (including direct and indirect jump). This solution constructs a read-only linear function table that stores function addresses during compilation. Then, IndexHooks checks the table to make program jump to the correct target address during runtime. However, IndexHooks faces limitations in backtracking CFG construction, which can lead to excessive memory usage; the linear structure of the function table is vulnerable to brute force tampering. Addressing the limitations of IndexHooks, this study develops an obfuscated CFI solution called LeafHooks. LeafHooks is implemented during compilation by the LLVM compiler, which performs static analysis and instrumentation on the LLVM Intermediate Representation (IR) code of a program. We make the following three innovations: 1) we propose a speculation-free identification method for indirect function calls by linear traversing and analyzing codes to obtain legal function information (function address); 2) we save this information into a function table in the form of a Balanced Binary Tree (also known as AVL), enhancing the fuzzification of function addresses to defend against brute force; 3) we design a method to simulate control tamper attacks on ARM64 architecture to verify the ability of LeafHooks to protection. LeafHooks shows less overhead than state-of-the-art solutions and reduces 2.9% and 0.55% overhead on average using UnixBench and Phoronix, respectively.