Technical Summary: RVDebloater

Problem Statement

As embedded devices, particularly Robotic Vehicles (RVs) like UAVs, UGVs, and ROVs, become more complex, their firmware grows in size, expanding the attack surface. These devices often operate in distinct modes (e.g., TAKEOFF, AUTO, LAND, RTL), where each mode requires only a specific subset of the total firmware code. However, existing debloating techniques suffer from significant limitations when applied to these mode-based embedded devices:

1. Fixed Granularity: Traditional fixed debloating techniques treat applications as monolithic entities, analyzing requirements over the entire lifetime. They fail to adapt to the changing requirements of different execution phases (modes), often leaving critical functions (e.g., disarm_motors) accessible during inappropriate modes (e.g., AUTO flight), creating safety and security risks.
2. Irreversibility: Adaptive techniques often rely on irreversible mechanisms like Seccomp-BPF to filter system calls. Once a call is filtered, it cannot be re-enabled. This is unsuitable for RVs, which frequently switch modes and may need to revert to previous modes (e.g., transitioning from AUTO back to LOITER).
3. Coarse Granularity: Many existing methods focus on system calls or hardware peripherals. They lack the fine-grained control necessary to restrict specific firmware functions (e.g., disarm_motors or output_min) that are critical for safety but dangerous if executed in the wrong mode.
4. Hardware Dependencies: Some techniques rely on Memory Protection Units (MPUs), which are often unavailable or limited in embedded systems (e.g., supporting only 8–16 regions), forcing coarse clustering that may still expose unneeded code.

Methodology: RVDebloater

The authors propose RVDebloater, a novel, adaptive, software-only debloating framework designed specifically for mode-based embedded devices. It operates at the function-level granularity and dynamically specializes firmware code based on the device's current operational mode.

The system consists of three main phases:

1. Analysis Phase (Offline)

RVDebloater automatically identifies the set of firmware functions required for each mode. It offers two approaches, allowing maintainers to choose based on risk tolerance:

• RVDebloater-dynamic (Dynamic Analysis): The system instruments the firmware to record mode switches and function executions. The device is then run through a set of missions (workloads). By profiling these runs, the system constructs a list of functions actually executed in each mode. The authors found that profiling as few as 10 missions was sufficient to identify all required functions for a mode with zero missed functions.
• RVDebloater-static (Static Analysis): The system uses the LLVM compiler and SVF (Simplified Value Flow) to construct a pruned call graph. To address the over-approximation inherent in static analysis (which often includes spurious targets for indirect calls), the authors introduced two pruning heuristics:
  • Signature-based Pruning: Filters indirect call targets based on argument types and return types, not just argument counts.
  • Address-based Pruning: Removes edges pointing to functions whose addresses do not appear in any reachable path from the entry point.
    This approach is more conservative, ensuring no required functions are missed, though it may retain more functions than the dynamic approach.

2. Guard Insertion Phase (Offline)

Once the required functions for each mode are identified, the firmware is instrumented using the LLVM compiler.

• Trampolines: A trampoline is inserted at the end of mode-switching functions to notify the monitor of a mode change.
• Control Flow Interposition: All indirect control flow transfer instructions (indirect calls and function returns) are replaced with calls to the RVDebloater Monitor. This forces all function dispatches to go through the monitor for validation.

3. Monitoring Phase (Runtime)

The instrumented firmware runs on the device. The RVDebloater Monitor enforces the debloating policy:

• Mode Switching: When a mode switch occurs, the monitor loads the specific access control table (configuration file) for the new mode, which lists the allowed functions.
• Function Validation: Before executing an indirect call, the monitor checks if the target function is in the current mode's allowed list.
  • If allowed: The monitor saves the return address, calls the function, and verifies the return address upon completion.
  • If denied: The monitor triggers a Fail-Safe mechanism (e.g., emergency landing or returning to the launch point) to prevent the device from executing unauthorized code.

Key Contributions

1. Adaptive, Function-Level Debloating: RVDebloater is the first framework to specialize firmware code at the function level for mode-based embedded devices, adapting dynamically to mode changes throughout the device's lifetime.
2. Dual Analysis Techniques: It introduces both static and dynamic analysis methods to identify per-mode code coverage, offering a trade-off between precision (dynamic) and safety/conservatism (static).
3. Software-Only Enforcement: Unlike prior work relying on hardware (MPU) or irreversible kernel mechanisms (Seccomp-BPF), RVDebloater uses a purely software-based approach that supports reversible mode switching and fine-grained function control.
4. Implementation and Evaluation: The system is implemented using the LLVM compiler, making it portable. It was evaluated on six different RVs (four simulated, two real) running ArduPilot and PX4 firmware.

Results

The evaluation demonstrated the following:

• Attack Surface Reduction:
  • RVDebloater-dynamic: Achieved an average 85% reduction in accessible firmware functions across different modes. It identified all required functions with zero missed functions after profiling 10 missions.
  • RVDebloater-static: Achieved an average 41% reduction. While less aggressive, it ensured zero false negatives (no required functions were blocked), though it had a higher false negative rate (44%) regarding unnecessary functions.
• Security Effectiveness: RVDebloater successfully prevented three realistic code-reuse attacks where an adversary attempted to hijack control flow to execute safety-critical functions (e.g., disarm_motors, output_min) in incorrect modes. In all cases, the system detected the unauthorized access and triggered Fail-Safe modes.
• Overhead:
  • Performance: Average runtime overhead of 3.9% on real RVs.
  • Memory: Average memory overhead of 4% (approximately 0.25 MB) for the instrumented firmware. Configuration files added negligible overhead.
  • Power: Estimated power consumption increase of 0.47%, deemed negligible.
  • Mission Impact: No increase in overall mission time was observed.

Significance

The paper claims that RVDebloater addresses critical gaps in embedded security by enabling reversible, fine-grained, and adaptive debloating. By recognizing that RVs operate in distinct modes with varying functional requirements, the system significantly reduces the attack surface without compromising the device's ability to switch modes or perform its mission. The authors emphasize that their approach is particularly vital for safety-critical systems where the ability to dynamically restrict dangerous functions (like motor disarming) based on the current flight phase is essential to prevent catastrophic failures. The work complements existing irreversible debloating techniques by providing a solution for devices that require dynamic feature re-enabling.