Abstract
Control-Flow Integrity (CFI) is a class of defensive techniques against control-flow attacks such as Return-Oriented Programming. We propose a light-weight CFI scheme for RTOS-based applications, TZmCFI, which utilizes TrustZone for Armv8-M, a hardware-assisted security feature for embedded systems with tight resource constraints. TZmCFI embodies several existing CFI techniques to provide a comprehensive protection. The traditional shadow stack technique is used to ensure stack integrity and validate function returns. To protect exception handlers, TZmCFI extends shadow exception stacks, which are a variant of the traditional shadow stack technique we proposed in our previous work, for RTOS integration and performance improvement. We conducted an experiment on Arm Versatile Express Cortex-M Prototyping System (V2M-MPS2+) to evaluate the run-time overhead of the proposed system.
Highlights
Arbitrary code execution is by far the most serious threat to software
We propose a light-weight Control-Flow Integrity (CFI) scheme for RTOS-based applications, TZmCFI, which utilizes TrustZone for Armv8-M, a hardware-assisted security feature for embedded systems with tight resource constraints
TZmCFI extends shadow exception stacks, which are a variant of the traditional shadow stack technique we proposed in our previous work, for RTOS integration and performance improvement
Summary
Arbitrary code execution is by far the most serious threat to software It is accomplished through the following two steps: the first step, code injection, loads malicious code onto the target’s memory, followed by the second step, control-flow hijacking, which transfers the control to the injected code. The common mitigation against this sort of attack is the use of a memory access policy called WÈX (‘‘write xor execute’’), which disallows memory regions from being writable and executable at the same time, effectively thwarting code injection. The simplest, non-trivial model is a static control-flow graph generated by static code analysis [1]. The precision of static models is limited by the conservatism of a generated control-flow graph as well as the limitation of and the difficulty in a practical pointer analysis. The caller in a single function call is just one of them, but a static model cannot express this restriction and allows the control to return to the incorrect caller
Sign-in/Register to view highlights & summary 
Published Version (
Free)
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call