Exploiting Security Dependence for Conditional Speculation Against Spectre Attacks

Abstract

Speculative execution side-channel vulnerabilities such as Spectre reveal that conventional architecture designs lack security consideration. This paper proposes a software transparent defense framework, named as Conditional Speculation, against Spectre vulnerabilities found on traditional out-of-order microprocessors. It introduces the concept of security dependence to mark speculative memory instructions which could leak information with potential security risks. More specifically, security-dependent instructions are detected and marked with suspect speculation flags in the Issue Queue. All the instructions can be speculatively issued for execution in accordance with the classic out-of-order pipeline. For those instructions with suspect speculation flags, they are considered as safe instructions if their speculative execution dose not refill new cache lines with unauthorized privilege data. Otherwise, they are considered as unsafe instructions and thus not allowed to execute speculatively. To pursue a balance of performance and security, we investigate two filtering mechanisms, Cache-hit based Hazard Filter and Trusted Page Buffer based Hazard Filter to filter out false security hazards. As for true security hazards, we have two approaches to prevent them from changing cache states. One is to block all unsafe access, the other is to fetch them from lower-level caches or memory to a speculative buffer temporarily, and refill them after confirming that they are on the correct execution path. Our design philosophy is to speculatively execute safe instructions to maintain the performance benefits of out-of-order execution while delaying the cache updates for speculative execution of unsafe instructions for security consideration. We evaluate Conditional Speculation in terms of performance, security, and area. The experimental results show that the hardware overhead is marginal and the performance overhead is minimal.

A Hardware Security Protection Method for Conditional Branches of Embedded Systems

“…Ref. [ 16 ] proposed a software protection method (Conditional Speculation) that limited the execution of memory instructions, which could resist attacks based on Spectre vulnerabilities. However, this method cannot prevent attackers from stealing branch information or monitoring the CFI.…”

“…Members of our lab have previously proposed various hardware security protection methods for embedded systems [ 11 , 12 , 13 , 14 , 15 ], but when applied, it was found that attackers could still exploit the vulnerabilities of BPUs to perform attacks. Therefore, we began to refer to existing methods [ 16 , 17 , 18 , 19 , 20 ].…”

A Hardware Security Protection Method for Conditional Branches of Embedded Systems

“…Ref. [15] proposed a software protection method (Conditional Speculation) that limited the execution of memory instructions, which could resist attacks based on Spectre vulnerabilities. However, this method cannot prevent attackers from stealing branch information or monitor the CFI.…”

“…Although the resource overhead of this method is low, it is difficult to balance the protection capability and performance overhead due to the simple mechanism of identifying spy processes. Conditional Speculation [15,23] dynamically identified dangerous access instructions by implementing different filtering mechanisms, but had a high performance overhead for some test programs. BRB [24] prevented malicious data injected by attackers from being used by assigning separate branch history tables (BHTs) to different programs, but had a high resource overhead and could not provide the effective protection for the shared parts.…”

“…Members of our lab have previously proposed various hardware security protection methods for embedded systems [11][12][13][14], but when applied, it was found that attackers could still exploit the vulnerabilities of BPUs to perform attacks. Inspired by existing research [15][16][17][18], we started to focus 2 on the security of the jump directions and jump addresses of branches. We tried to restrict the target address of the jump instruction to be the starting address of a basic block (BB).…”