# Nanovised Control Flow Attestation
## 2 Related Work  
Research in CFI is vast and is available in the hardware and the software. ARMv8.3-PAuth [3] adds the Pointer Authentication Code (PAC) feature to the ARM processors. PAC validates whether the target of an indirect branch is valid (Figure 1). PAC can be used for construction of CFI systems. Unfortunately, currently ARMv8.3 processors are not available, thus not allowing it to be embedded in our solution. In addition, the authentication of PAC is performed in EL0, while our system executes in EL2. Clang CFI [5] is designed to detect schemes of undefined behavior in C++ programs. These schemes have been optimized for performance. The schemes rely on LTO (Link Time Optimization). For better efficiency, the program must be structured such that certain object files are compiled with CFI enabled. The schemes focus on casting between types, incorrect virtual calls and indirect virtual calls. It can be interesting to perform Clang's CFI in our Nanovisor. There are several control flow attestation systems similar to C-FLAT, all having similar limitations. Lo-Fat [6] is similar system for RISC-V architecture. A similar system for the bare metal system was proposed in [7]. Another system for remote control flow attestation of embedded devices was proposed by [PERSON] et al. [8]. Their system is implemented in ARM's TrustZone. ReCFA [9] describes several improvements to the attestation scheme. In particular, ReCFA requires only the binary and not the source code form of the program. In addition, the control flow information is condensed in multiple way, including compression, in order to allow faster and cheaper delivery of this information to the verifier. TinyCFA [10] provides control flow attestation for low-end MCUs, such as ATmega32. [PERSON] et al. proposed [11] to apply the control flow attestation mechanism only to potentially vulnerable parts of the program. Our advantage against all of these is the ability to support GPOS and normal multi-process and multi-threaded applications. Kernel CFI (kCFI) [12] demonstrates CFI for the Linux kernel. It combines static analysis at the source and binary levels and creates a restrictive CFI policy. Compared to other kernel CFI approaches, it achieves a small overhead, approximately 2%, and supports dynamic module insertion. kCFI is compiler-based technology and, therefore, does not rely on any runtime supervisor or routine, avoiding overheads. Figure 1: PAC. MoCFI [13] (Mobile CFI) is a CFI framework intended for ARM7. It instruments the binary on the fly and offers protection from code injection attacks and code reuse attacks (such as return-to-libc). Unlike C-FLAT, the attestation is performed in a non TEE environment, and the binary analysis is performed offline. However, it is only fair to say that it is possible to migrate the runtime enforcement into our Nanovisor. PathArmour [14] is a context-sensitive CFI (CCFI) for the Intel platform. Its uniqueness is its ability to detect wrong code path flows; for example, if function B can be called from both A and C, but the current context is A to B, but the actual path is C to B, then PathArmour can detect this. PathArmour uses a kernel module to monitor paths. To reduce the overhead, it mainly focuses on system call tracing and relies on x86_64 branch recording features. Unlike C-FLAT, it does not run in ARM, and the path monitoring is not performed in a TEE. Another technology for ROP attacks is the kBouncer [15]. KBouncer is a binary CFI for the \(\times\)86 platforms. It focuses on ROP attacks protection through the use of Intel's LBR (Last Branch Recording). LBR is a set of registers that record the last branches; it is transparent to the running application and, therefore, incurs zero overhead for storing the branches. In the area of static attestation, we find SWATT (Software-based Attestation Technique) [16] for embedded devices. SWATT examines the memory content for viruses. Another software in this area is Pioneer [17].