1 Introduction
Memory safety violation is considered one of the most critical software vulnerabilities leading to both correctness and security problems. in 2020, the Common Weakness Enumeration (CWE) community listed three types of memory safety violation among the five most impactful and serious software issues [1]. A memory safety violation can manifest from software or hardware behavior. For illustration purpose, let us consider the examples in Fig. 1. It shows how a memory safety violation (buffer overflow) can be the result of a vulnerability in software or in hardware. A software (or software-induced) memory safety violation can be prevented by software defenses such as bounds-checking [2]. However, a hardware (or hardware-induced) memory safety violation can bypass such defenses in software within the CPU pipeline as a result of misprediction or out-of-order optimizations. For example, a Spectre-PHT attack [3] will mistrain the branch predictors to temporarily bypass the bounds-checking in software within speculative execution, and then leak the out-of-bound data through a side channel. Many works either in software or hardware have addressed memory safety violations. However, existing works suffer from the following major shortcomings:
Most existing works have focused on defense against only software memory safety violations [4], [5], [6], or defense against only hardware memory safety violations [7], [8], or defense against software violations with partial defense against hardware violations [9], [10]. Cryptographic Capability Computing (\text{C}^{3}) [11] provides uniform defense against both software and hardware memory safety violations, yet it requires memory encryption which may not be necessary in some scenarios. Both No-FAT [12] and HeapCheck [13] performs bounds checking on both non-speculative and speculative memory access and raise exceptions on violations. An uniform, general hardware defense against both software and hardware violations not only incurs lower access overheads but also provides economy of mechanisms and wide coverage of defense.
A comparison of hardware and software memory safety violations. Due to a branch misprediction or lack of bounds check, respectively, a malicious input (int offset) can cause memory safety violations in hardware or in software.
Existing works have addressed software memory safety violations based on either blocking the malicious behaviors (i.e., blocklisting) [9], [14] or allowing the benign behaviors (i.e., allowlisting) [5], [15]. However, for hardware memory safety violations, most existing defense works only focus on detecting or preventing specific malicious behaviors [9] or their consequences [16]. These defenses for hardware violations are specific to the exploits and can be considered ad-hoc solutions. If any future exploit exhibits different behaviors, the attacker can circumvent the defense mechanism.