Cache Partitioning for Speculative Execution Security
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Modern processors face vulnerabilities due to shared cache structures, allowing lower-privileged software to potentially access sensitive information from higher-privileged software through speculative execution attacks, which existing mitigation techniques may not adequately address while maintaining performance.
Innovation Solution
Implementing a cache partitioning scheme that isolates cache regions for higher-privileged and lower-privileged entities by using a partition table to manage cache storage, ensuring that data blocks are stored in specific way and set partitions, and employing invalidation commands to maintain security and performance.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Speed
If a shared cache structure is used to accelerate processor performance, then cache access speed is improved, but security vulnerabilities arise allowing speculative execution attacks between different privilege levels
Solution Approach 1:
The cache is segmented into multiple independent ways (e.g., way 0, way 1, way 2, way 3) that can be independently controlled and invalidated. This segmentation allows the system to isolate cache regions associated with different privilege levels, preventing speculative execution attacks while maintaining cache performance for authorized accesses.
Solution Approach 2:
Different cache ways are assigned to different privilege levels (e.g., higher-privileged software gets specific ways, lower-privileged software gets other ways). This local quality differentiation ensures that each privilege level has dedicated cache resources, eliminating cross-contamination through speculative execution while preserving fast cache access for legitimate operations.
2Reliability
If cache partitioning is implemented to mitigate security vulnerabilities, then security is improved, but cache management complexity increases
Solution Approach 1:
The cache controller automatically manages the partitioning and invalidation of cache ways based on privilege level information embedded in memory access requests. This self-service mechanism eliminates the need for complex software-based cache management, as the hardware automatically enforces security policies by identifying the privilege level and directing accesses to appropriate cache ways.
Solution Approach 2:
The system pre-assigns specific cache ways to specific privilege levels before execution begins. This preliminary action simplifies runtime management, as the cache controller only needs to lookup the privilege level and route to the pre-assigned ways, rather than dynamically computing complex partitioning schemes during execution.
3Reliability
If traditional cache flushing is used to prevent speculative execution attacks, then security is improved, but performance deteriorates due to loss of cached data
Solution Approach 1:
Instead of flushing the entire cache, the cache is segmented into independent ways that can be selectively invalidated. When a security concern arises, only the specific cache way associated with the lower-privileged software is invalidated, while other ways retain their cached data. This segmented invalidation maintains security while preserving performance-critical cached data.
Solution Approach 2:
The system performs partial invalidation of only the necessary cache region (specific cache way) rather than excessive full-cache flushing. This partial action is sufficient to prevent speculative execution attacks while minimizing performance impact by retaining useful cached data in other cache ways.
Data Source
AI summary
Managing a cache includes parsing a physical address of a data block to determine a partition identifier (ID) and a tag; the partition ID compared against a partition table storing partition IDs. The partition table indicates at least one way partition and at least one set partition corresponding to the partition ID. Based on the partition table, a way partition is determined at which to store the data block, corresponding to a subset of columns of a cache and, based on the partition table and the tag, a set partition is determined at which to store the data block, corresponding to a subset of rows of the cache. A cache address is generated for the data block within a first region of the cache corresponding to an intersection of the way partition and the set partition. The data block is stored to the cache according to the cache address.