A micro-architectural side-channel attack defence method supporting speculative time prefetching
Patent Information
- Application Number
- CN202611260414.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-19
- Publication Date
- 2026-11-03
AI Technical Summary
Existing technologies are insufficient to effectively defend against side-channel attacks by hardware prefetchers during speculative execution, especially cross-core, non-cache-dependent attacks, and defensive measures may result in performance loss.
A speculative prefetch buffer and shadow prefetch training engine mechanism are adopted. Speculative prefetch requests and training feedback are isolated by speculative labels to ensure that they do not pollute the global microarchitecture state before submission, and are uniformly merged or discarded upon submission.
It effectively prevents side-channel attacks while maintaining the performance gains of hardware prefetching, reducing performance losses due to prefetching during commit, and preventing information leakage across cores and domains.
Smart Images
Figure CN123034931A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer architecture and microarchitecture security, and in particular to a microarchitecture side-channel attack defense method that supports speculative prefetching. Background Technology
[0002] Modern high-performance processors typically rely on microarchitectural optimization techniques such as speculative execution, out-of-order execution, branch prediction, and hardware data prefetching to improve instruction-level parallelism and hide main memory access latency. When the result of a conditional branch has not yet been parsed, the processor fetches, decodes, and executes instructions on the predicted path in advance based on the branch prediction result. When there is a long latency in memory access, the hardware prefetcher issues data read requests to the cache hierarchy or lower-level memory hierarchy in advance based on historical access patterns. These techniques significantly improve pipeline utilization and application throughput, but also introduce security semantics differences between the architectural state and the microarchitectural state.
[0003] When a speculative execution path is proven wrong, the processor can roll back architectural states such as registers, program counters, and memory-visible results. However, microarchitectural states such as cache occupancy, replacement states, TLB states, branch predictor states, and prefetcher internal metadata are often not fully rollbackable. The Spectre attack proposed by Kocher et al. (Kocher P, Horn J, Fogh A, et al. Spectre Attacks: Exploiting Speculative Execution[C] / / 2019IEEE Symposium on Security and Privacy (SP). 2019: 1-19.) demonstrates that attackers can induce the processor to access secret-related data within a transient execution window and recover protected information by exploiting microarchitectural traces such as caches left behind by the speculative path.
[0004] To address the aforementioned issues, Yan et al. proposed InvisiSpec (Yan M, Choi J, Skarlatos D, et al. InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy[C] / / 2018 51st Annual IEEE / ACM International Symposium on Microarchitecture(MICRO). 2018.), which isolates cache state changes caused by unsafe loading through speculative buffers; Ainsworth proposed GhostMinion (Ainsworth S. GhostMinion: A Strictness-Ordered Cache System for Spectre Mitigation[C] / / 2021 54th Annual IEEE / ACM International Symposium on Microarchitecture(MICRO). 2021: 592-606.), which protects cache hierarchy, MSHR, and prefetch-related state using strict ordering and small speculative buffers. This type of invisible speculation scheme proves the feasibility of "isolate first, then disclose", but its main protection object is still the speculation loading and caching layer, which is not enough to directly cover internal metadata such as prefetcher training entries, confidence, stride and replacement state.
[0005] Hardware prefetchers typically maintain metadata such as historical access addresses, stride length, confidence level, recent usage status, and context or instruction pointer-related indexes. Taking an instruction pointer stride prefetcher as an example, this type of prefetcher tracks the data access sequence generated by the same load instruction address, updating the stride length and confidence level fields based on stride length changes between consecutive access addresses. When the confidence level reaches a threshold, the prefetcher initiates a read request in advance based on the current address and predicted stride length. If the prefetcher only uses the low-order bits of the instruction pointer for indexing, load instructions from different programs may experience index collisions, allowing attackers to influence or probe the victim's prefetcher entries.
[0006] The AfterImage attack proposed by Chen et al. (Chen Y, Pei L, Carlson T E. AfterImage: Leaking Control Flow Data and Tracking Load Operations via the HardwarePrefetcher[C] / / Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2. 2023: 16-32.) leverages the shared and indexed features of the Intel instruction pointer stride prefetcher and constructs prefetcher state detection primitives to leak control flow and load activity between different protection domains. This work demonstrates that even without considering traditional cache hit states as the sole source of leakage, the internal state of the prefetcher itself can form a continuously observable information channel.
[0007] Furthermore, Chen et al. proposed PREFETCHX (Chen Y, Hajiabadi A, Pei L, Carlson TE. PREFETCHX: Cross-Core Cache-Agnostic Prefetcher-Based Side-Channel Attacks[C] / / 2024 IEEE International Symposium on High-Performance Computer Architecture (HPCA). 2024: 395-408.), revealing that the XPT prefetcher in Intel server processors can be used for cross-core, cache-independent side-channel and covert-channel attacks. This result indicates that defenses should not be limited to the first-level or last-level cache, but should also limit the propagation of speculative prefetch requests, prefetcher training states, and cross-core visible states.
[0008] The closest existing research to this invention is Secure Prefetching for SecureCache Systems proposed by Nath et al. (Nath S, Navarro-Torres A, Ros A, Panda B. Secure Prefetching for Secure Cache Systems[C] / / 2024 57th IEEE / ACM International Symposium on Microarchitecture (MICRO). 2024: 92-104.). This study analyzed the interaction between prefetchers such as IP-Stride, IPCP, Bingo, SPP+PPF, and Berti and the GhostMinion secure caching system, and found that moving the prefetcher training and request triggering from the memory access phase to the commit phase would result in an additional performance loss of about 3% to 4%, mainly due to commit-late prefetching and training timing distortion. To address this, the proposed Security Update Filter (SUF) reduces redundant cache update traffic during commits, and Timely Security Berti (TSB) temporarily stores access times and fetch latency during memory access and filling phases, completing training and selecting a more timely prefetch distance during the commit phase. This scheme still relies on commit-time training and commit-time triggered prefetching as its security foundation, focusing on compensating for the traffic and timeliness loss associated with prefetching after commit. It does not prematurely fire real prefetch requests during the unparsed speculation period, nor does it simultaneously isolate prefetch data from the main prefetcher metadata through independent data buffers and shadow training structures.
[0009] Therefore, a new defense architecture is urgently needed to enable the processor to distinguish between speculative prefetching behavior that "can be traded for physical time in advance but cannot be immediately disclosed" and high-risk prefetching behavior that "must wait for security confirmation"; to keep speculative prefetched data in an isolated space before commit; to keep prefetcher training feedback in a shadow space before commit; and to uniformly merge or discard it during branch commit or rollback. This architecture should cover cache signal amplification attacks and prefetcher metadata corruption attacks with minimal hardware overhead, while minimizing the performance degradation caused by prefetching during commit. Summary of the Invention
[0010] This invention provides a microarchitecture side-channel attack defense method that supports speculative prefetching. It proposes an isolated defense mechanism that allows secure prefetching during the speculation phase but does not allow it to pollute the global microarchitecture state, thereby blocking the speculative prefetching side channel while preserving the performance benefits of hardware prefetching as much as possible.
[0011] A microarchitecture side-channel attack defense method supporting speculative prefetching, applied to a processor system including an out-of-order execution pipeline, a reordering buffer, a load-memory queue, at least one level of data cache, and a hardware prefetcher, the method comprising: During speculative execution, speculative tags are attached to prefetch requests generated by load instructions, prefetch instructions, or hardware prefetchers. Based on the speculative tag, determine whether the prefetch request is in a speculative path that has not yet been submitted, and redirect the prefetch request in the speculative path to a speculative prefetch buffer that is independent of the global cache level. The prefetcher training feedback, stride update, confidence update and candidate prefetch address learning results generated during the speculation period are redirected to the shadow prefetch training engine instead of directly modifying the prediction entries of the master prefetcher. When the corresponding speculative path is verified to be correct and the relevant instructions reach the submission stage, the data buffer entries in the speculative prefetch buffer that meet the safe merging conditions are written into the target cache level, and the training states in the shadow prefetch training engine that meet the submission conditions are merged into the main prefetcher. When the corresponding speculative path is rolled back, an exception occurs, it is interrupted, or its prefetch visibility classification does not meet the merging conditions, the data buffer entries in the speculative prefetch buffer and the training state in the shadow prefetch training engine are discarded, thereby preventing the prefetch behavior during speculative execution from changing the microarchitectural state that can be observed by other execution contexts.
[0012] Furthermore, the speculative label includes at least one or more of the following: branch speculation identifier, reorder buffer sequence number, branch mask, load queue sequence number, hardware thread identifier, address space identifier, privilege level identifier, security domain identifier, source prefetcher identifier, and prefetch visibility classification. This label is used to restrict the propagation of speculative prefetch data and shadow training state between different security domains. Through this label, the processor can determine whether an unresolved branch exists when a prefetch request is generated, whether it depends on uncommitted load results, whether it crosses security domains, and whether its returned data can be loaded and used by the request before submission.
[0013] The speculative prefetch buffer is used to temporarily store prefetched data returned during speculation. This buffer can be placed before the Level 1 data cache, between the Level 1 and Level 2 caches, or between the Level 2 and last-level caches. Regardless of its location, the speculative prefetch buffer is logically isolated from the main cache hierarchy: its entries do not participate in the global cache coherency protocol, do not change the main cache replacement state, do not update shared hit statistics, and do not expose hit or miss information to other hardware threads.
[0014] Furthermore, the speculative prefetch buffer includes multiple data buffer entries, each of which includes at least a valid bit, a physical address or address digest, cache line data, a data ready bit, a speculative tag, a security domain identifier, a cache hierarchy target bit, a source prefetcher identifier, and an evictation status bit.
[0015] Furthermore, the speculative prefetch buffer does not participate in the shared state propagation in the processor global cache coherence protocol, does not update the main cache replacement state, does not expose the hit state to other hardware threads, and only allows access to its entries by requests carrying the same speculative label or those that have been submitted and verified.
[0016] The shadow prefetch training engine is used to temporarily store training updates to the prefetcher state during speculation. For instruction pointer stride prefetchers, the shadow prefetch training engine can mirror the last accessed address, current stride, predicted stride, confidence level, and replacement state; for flow prefetchers or correlation prefetchers, the shadow prefetch training engine can mirror the flow direction, flow depth, correlation address history, and prediction confidence level. Training feedback generated by all speculative paths is first written to the shadow structure and is only allowed to be merged into the main prefetcher when the corresponding instruction or triggering event is committed.
[0017] Furthermore, the shadow prefetch training engine includes a shadow history table, a shadow stride field, a shadow confidence field, and a shadow replacement status field. The shadow prefetch training engine uses the same or compatible indexing method as the main prefetcher, but its update results are physically isolated from the main prefetcher before submission.
[0018] Furthermore, the secure merging conditions include: the load instruction, prefetch instruction, or hardware prefetcher-related triggering event that generated or triggered the prefetch request has been submitted or verified; the address of the prefetch request does not depend on the rolled-back transient data; the security domain identifier of the prefetch request is consistent with the currently submitted security domain identifier; and the prefetch data has not been marked as propagating across permissions, processes, or security domains.
[0019] Alternatively, for prefetch requests whose address calculations depend on uncommitted load results, unresolved branch paths, or protected data values, the method marks them as security-sensitive prefetch requests and allows them to remain in the reserved state of the launch queue or speculative prefetch buffer until the corresponding dependency is committed and confirmed, without allowing them to modify the main cache and the main prefetcher.
[0020] Alternatively, for prefetch requests whose address calculations depend solely on committed register values, committed memory values, or prediction states that already exist in the master prefetcher before the speculation path begins, read requests can be issued to lower-level memory tiers during speculation, but the returned data is only filled into the speculation prefetch buffer and does not affect the master cache, master prefetcher, shared replacement state, or cross-core visible state before commit.
[0021] Furthermore, when the speculative path is submitted, the data buffer entries in the speculative prefetch buffer are batch merged according to the reorder buffer sequence number, address conflict relationship and cache hierarchy target bit; if the same cache line already exists in the target cache, only the data readiness status or prefetch usefulness statistics that can be safely updated are updated, and the cache line is not written repeatedly.
[0022] Furthermore, when the speculative path is rolled back, the speculative prefetch buffer clears the corresponding entries according to the branch speculative identifier, the shadow prefetch training engine cancels the corresponding training update according to the same branch speculative identifier, and keeps the main prefetcher in the state before the speculative path started.
[0023] Furthermore, the hardware prefetcher includes an instruction pointer stride prefetcher, a data stream prefetcher, an adjacent row prefetcher, a spatial prefetcher, a correlation prefetcher, or a combination thereof; a shadow training structure or a shared shadow training structure is configured for different hardware prefetchers.
[0024] Furthermore, the speculative prefetch buffer is configured as a fully associative, set-associative, or direct-mapped structure, with 8 to 128 entries, and prioritizes the elimination of entries that are invalid, merged, whose corresponding branches have been rolled back, or whose prefetch usefulness is below a threshold. The shadow prefetching training engine performs mirror calculations on the training feedback of the main prefetcher. The training feedback includes at least the previous access address, the current access stride, the predicted stride, the confidence increase or decrease, the predicted hit state, and the replacement candidate state.
[0025] Furthermore, when a context switch, privilege level switch, security domain switch, or virtual machine switch occurs in the processor system, the uncommitted entries in the speculative prefetch buffer and the shadow prefetch training engine are cleared, while the committed entries in the main prefetcher that match the security domain identifier are retained.
[0026] Compared with the prior art, the present invention has the following beneficial effects: This invention adds speculative label generation logic to the processor's prefetch request generation path, a speculative prefetch buffer to the cache filling path, a shadow prefetch training engine to the prefetcher training path, and a commit merging controller to the commit phase. These components work in conjunction with a reordering buffer, a load storage queue, a branch parsing unit, and a cache hierarchy to preserve the performance gains of hardware prefetching as much as possible while blocking speculative prefetch side-channels. Attached Figure Description
[0027] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0028] Figure 1 This is a schematic diagram of the overall structure of the processor microarchitecture that supports speculative prefetching in an embodiment of the present invention.
[0029] Figure 2 This is a flowchart illustrating the lifecycle of a prefetch request in an embodiment of the present invention.
[0030] Figure 3 This is a schematic diagram of the prefetch buffer entry structure in an embodiment of the present invention.
[0031] Figure 4 This is a flowchart illustrating the state isolation and commit merging process between the shadow prefetch training engine and the main prefetcher in an embodiment of the present invention. Detailed Implementation
[0032] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0033] It should be noted that, unless otherwise specified, the features in the following embodiments and implementation methods can be combined with each other.
[0034] The implementation process of this invention will be described in detail below through seven parts.
[0035] 1. Overall microarchitecture structure.
[0036] like Figure 1 The diagram shown is a schematic of the overall microarchitecture structure of a processor supporting speculative prefetching in an embodiment of the present invention. The diagram illustrates the connections between the out-of-order execution pipeline, reordering buffer, load storage queue, hardware prefetcher, speculative prefetch buffer, shadow prefetch training engine, commit merging controller, and cache hierarchy.
[0037] In this embodiment, the processor is a general-purpose processor core that supports out-of-order execution. The processor core includes an instruction fetch unit, a decoding unit, a renaming unit, a scheduling queue, an execution unit, a load-memory queue, a reordering buffer, a branch parsing unit, a level 1 data cache, a level 2 cache, and a hardware prefetcher. The hardware prefetcher can generate prefetch requests based on the access address, instruction address, historical stride, or data flow pattern to be loaded as needed.
[0038] This embodiment adds a speculative prefetch buffer between the hardware prefetcher and the cache hierarchy, and adds a shadow prefetch training engine as a bypass in the hardware prefetcher training path. The speculative prefetch buffer can be understood as a sandbox for prefetched data; it receives data returned during speculation but does not allow this data to enter the main cache before commit. The shadow prefetch training engine can be understood as a sandbox for prefetcher metadata; it receives training feedback during speculation but does not allow this feedback to modify the main prefetcher before commit.
[0039] When a load instruction in the load storage queue issues a demand access, the hardware prefetcher determines whether to generate a prefetch request based on the access and its internal state. If the demand access or prefetch request is after an uncommitted branch, the speculative label generation logic adds a branch speculative identifier and a reorder buffer number to it. If the access is no longer after any unresolved branch, the prefetch request can be marked as a non-speculative request and processed according to the traditional path.
[0040] For speculative requests, the commit merge controller first reads the dependency information provided by the reordering buffer and the load storage queue to determine whether the address of the request depends on data that has not yet been committed. If it does not depend on data, the prefetch request is allowed to access the lower-level cache or memory in advance; if it does depend on data, the prefetch request can be temporarily stored in the verification queue or only the shadow candidate state is updated until the dependency instruction is committed. In either case, speculative requests cannot be written to the main cache or used to train the main prefetcher before they are committed.
[0041] 2. Speculate on the structure and access rules of the prefetch buffer.
[0042] like Figure 2 The diagram shown is a lifecycle flowchart of a speculative prefetch request in an embodiment of the present invention. The diagram illustrates the stages of prefetch request generation, speculative tag appending, security classification, request emission, data return, commit merging, and rollback discarding.
[0043] like Figure 3The diagram shown illustrates the structure of the speculative prefetch buffer entries in an embodiment of the present invention. The speculative prefetch buffer consists of several entries, each including a valid bit, an address field, a data field, a data ready bit, a speculative tag field, a security domain identifier field, a source prefetcher identifier field, a prefetch visibility classification field, a target cache hierarchy field, and a status field. The address field can store the complete physical address, the physical page number plus the cache line offset, or an address digest for matching. The data field stores cache line data returned from the lower-level storage hierarchy. The speculative tag field associates the speculative path that generated the prefetch request. The security domain identifier field defines the security domain of the accessor. The status field indicates whether the entry is in a pending return, returned, pending merging, merged, or pending discard state.
[0044] When a speculative prefetch request hits the speculative prefetch buffer, the processor does not directly expose the hit as a global cache hit. Request loading can only retrieve data from the buffer if the speculative tag carried by the request exactly matches a data buffer entry, or if the data buffer entry has been marked as committable by the commit merge controller. For requests from other hardware threads, other processes, or other security domains, even if the address is the same, the hit status of that entry cannot be observed.
[0045] When a speculative prefetch request misses the speculative prefetch buffer and is allowed to be issued early by a security-sensitive prefetch filter, the request is sent to the next-level cache or memory system. The returned data does not enter the first-level data cache, nor does it update the last-level cache replacement state. Instead, it is written to the corresponding speculative prefetch buffer entry via a tagged return channel. If the corresponding speculative path has already been rolled back before the return, the returned data is either discarded directly or becomes invalid immediately after being written.
[0046] The prefetch buffer's eviction policy preemptively selects invalid entries, merged entries, entries whose corresponding branches have been rolled back, and entries with low usefulness. When a valid entry that has not yet been committed must be evictioned, only its data and tag are discarded; no write-back or replacement is performed on the main cache. Therefore, attackers cannot influence the main cache state by creating buffer pressure, nor can they infer whether prefetching has occurred by observing main cache replacement behavior.
[0047] During the processor commit phase, if the branch speculation identifier of a speculative prefetch buffer entry has been verified as correct, and its reorder buffer sequence number is no later than the current commit boundary, the commit merge controller checks whether the target cache already contains the same cache line. If the target cache misses, the data is written to the target cache as normal prefetch padding; if the target cache hits, only the safe-to-use prefetch usefulness statistics are updated, or the entry is released directly. After the merge is complete, the entry is marked as merged and can be reclaimed.
[0048] 3. Structure and merging rules of the shadow prefetching training engine.
[0049] like Figure 4 The diagram shown illustrates the state isolation and commit merging process between the shadow prefetch training engine and the main prefetcher in an embodiment of the present invention. It shows the process of writing speculative training feedback into the shadow structure, merging it sequentially upon commit, and discarding it upon rollback.
[0050] The shadow prefetch training engine protects the main prefetcher's internal metadata from being contaminated by transient execution paths. In this embodiment, the main prefetcher is an instruction pointer stride prefetcher, whose entries include the instruction pointer index, last access address, predicted stride, confidence level, and replacement state. The shadow prefetch training engine maintains a set of shadow entries for each speculative path. Each shadow entry includes at least the shadow index, shadow last access address, shadow stride, shadow confidence level, source reordering buffer number, branch speculation identifier, and security domain identifier.
[0051] When a load access in the speculative path reaches the prefetcher training interface, the training feedback is not written to the main prefetcher, but to the shadow prefetch training engine. The shadow prefetch training engine calculates whether the stride matches, whether the confidence level increases or resets, whether candidate prefetch addresses are generated, and whether table entries need to be replaced, using the same training algorithm as the main prefetcher. For non-speculative accesses, the training feedback can be written directly to the main prefetcher, or it can be written to the shadow structure first and merged in the same cycle or commit cycle.
[0052] When the shadow prefetch training engine generates candidate prefetch addresses based on speculative feedback, these candidate addresses still need to pass through a security-sensitive prefetch filter and speculative label generation logic. If a candidate address is allowed to be emitted early, its returned data enters the speculative prefetch buffer; if a candidate address is marked as high-risk, no real memory request is issued, but the shadow training state can be retained to restore the predictive continuity of the prefetcher after submission.
[0053] When a corresponding speculative path is committed, the commit merge controller reads the shadow entries and merges them into the primary prefetcher in the actual commit order. During merging, if the corresponding entry in the primary prefetcher has not been updated by other committed events since the start of the speculative path, the primary entry can be directly overwritten by the shadow entry or incrementally updated. If the primary entry has been updated by other committed events, the controller replays the training feedback according to the commit order, or chooses conservative merging based on confidence, safety domain identifier, and replacement strategy.
[0054] When the speculative path is rolled back, the shadow prefetch training engine batch-clears the relevant entries based on the branch speculation identifier. Since the master prefetcher never receives these speculative training feedbacks, attackers cannot leave metadata traces for sustainable observation by corrupting master prefetcher entries, lowering master prefetcher confidence, or altering the master prefetcher stride field.
[0055] 4. Commit, rollback, and context switching process.
[0056] When the branch resolution unit confirms that a speculative path is correct, it does not immediately publish all relevant speculative prefetch states, but waits for the relevant instructions to reach the commit boundary. This avoids inconsistent microarchitectural visibility caused by later instructions occurring earlier in case of exceptions or interruptions. Once the commit boundary advances to the reorder buffer sequence number corresponding to a prefetch request, the commit merge controller performs a merge check on it.
[0057] The merge checks include address permission checks, security domain identifier consistency checks, dependency commit checks, cache consistency security checks, and duplicate padding checks. If the checks pass, the data in the speculative prefetch buffer is written to the target cache hierarchy, and the training feedback in the shadow prefetch training engine is merged into the main prefetcher. If the checks fail, the relevant entries are discarded.
[0058] When a branch prediction error, exception, page fault, interruption, or machine purge occurs, the reordering buffer provides the commit merge controller with the branch mask or sequence range to be purged. The commit merge controller then scans or indexes the prefetch buffer and shadow prefetch training engine based on this information, purging all relevant entries. The purge operation does not require access to the main cache or undoing the master prefetcher state, as these states were not modified before the commit.
[0059] When context switching, process switching, virtual machine switching, entry into or exit from a trusted execution environment, or switching between kernel mode and user mode occurs, the system can choose to clear all uncommitted speculative prefetch buffer entries and shadow training entries. For entries already committed to the main prefetcher, the system can choose to retain, partition retain, or clear them based on the address space identifier and security domain identifier. Compared to completely clearing the prefetcher, this strategy reduces retraining overhead; compared to completely sharing the prefetcher, this strategy reduces the risk of cross-domain leakage.
[0060] 5. Defense effectiveness against typical attack paths.
[0061] To counter attacks that amplify cache side-channel signals using prefetchers, attackers attempt to trigger multiple additional prefetch cache lines by making secret-related accesses in a transient path, and then identify these cache lines by cache access times after a rollback. In this invention, even if additional prefetch cache lines are read in advance, they only enter the speculative prefetch buffer and are not written to the main cache before commit. If the transient path is eventually rolled back, the data buffer entries are discarded, so the attacker cannot recover the secret from the main cache hit state in subsequent stages.
[0062] To address attacks that exploit prefetcher metadata to create independent channels, attackers attempt to alter the confidence, stride, or replacement state of the master prefetcher during transient paths and determine the secret bit by checking if the prefetcher can still trigger prefetching after a rollback. In this invention, all training feedback from the transient path is written to the shadow prefetch training engine, and the master prefetcher state remains unchanged. If the path is rolled back, the shadow state is deleted; if the path is committed, it has become a legitimate execution and is not considered a case of leaked information due to incorrect speculation. Therefore, speculation errors cannot leave persistent state differences in the master prefetcher.
[0063] To address prefetcher state collision attacks across processes or security domains, attackers attempt to construct shared entries using identical or similar prefetcher indices and then corrupt or trigger these entries through victim access. This invention introduces security domain identifiers for speculative labels and master prefetcher entries, or checks the consistency of security domain identifiers during shadow training merging. Even if index collisions exist across different domains, uncommitted training states will not propagate across domains, and committed states can be partitioned or selectively retained by domain, thereby reducing the risk of leakage caused by cross-domain collisions.
[0064] To address the potential risks of using the speculative prefetch buffer itself as a side channel, this invention employs same-label hit rules, delayed public disclosure of performance counters, replacement state isolation, and cross-domain invisibility strategies. Attackers cannot probe the existence of data buffer entries from other threads or other security domains, nor can they indirectly observe data buffer entries through the main cache replacement state. For hits within the same speculative path, this invention only allows them to be used to improve legitimate execution performance and does not permit their persistence after rollback.
[0065] 6. Performance and hardware overhead analysis.
[0066] The performance advantage of this invention stems from its hierarchical handling of speculative prefetching. Strict commit-time prefetching requires all prefetch requests to wait until commit before being emitted, resulting in prefetched data typically arriving later than the required access. In contrast, this invention allows address-safe prefetch requests to access lower storage tiers ahead of time during speculation, returning data that is already in the speculative prefetch buffer before commit. When the program executes correctly along the predicted path, commit merging can quickly move data into the cache or forward it directly to the required load, thereby reducing pauses.
[0067] The hardware overhead of this invention mainly comes from the speculative prefetch buffer, the shadow prefetch training engine, and the commit merge controller. The speculative prefetch buffer can use 16 to 32 cache line entries to meet common prefetch depths; the shadow prefetch training engine only needs to store metadata for the prefetcher training feedback in the uncommitted speculative window, and its capacity can be less than or equal to the number of loading entries in the reorder buffer that may trigger prefetching; the commit merge controller reuses existing branch masks and commit boundary information, and the logical complexity is controllable.
[0068] In terms of implementation, this invention does not require changes to the instruction set semantics, nor does it require software developers to manually annotate all sensitive branches. For low-cost implementations that do not support hardware security classification, a conservative strategy can be adopted, allowing only certain secure sequential prefetches to be emitted in advance, while the rest of speculative prefetches enter a state of pending verification. For high-performance implementations, a more refined classification can be achieved by combining taint bits, memory dependency prediction, and page table permission information.
[0069] This invention uses the Gem5 simulator to verify security and demonstrate performance. Gem5 is a clock cycle-level simulator widely used in computer architecture research. We use SPECspeed 2017 Integer and SPECspeed 2017 Floating Point suites as benchmark examples to test performance.
[0070] 7. Comparison with existing technologies.
[0071] Compared to the temporary prefetcher disabling method used by PreFence, this invention does not require user programs to label safety-critical code sections, nor does it require the operating system scheduler to repeatedly start and stop the prefetcher during context switching and SMT sharing scenarios. This invention labels and classifies speculative requests for safety within the processor, isolating only uncommitted data and training states, while still allowing safe-to-advance requests to be emitted during speculative periods.
[0072] Compared to the prefetcher state collisions, confidence corruption, and cross-core shared attack paths disclosed by AfterImage and PREFETCHX, this invention not only restricts the visibility of prefetcher entries across processes or cores, but also redirects the stride, confidence, and replacement state updates generated during speculation to the shadow prefetch training engine. When an erroneous path is rolled back, the main prefetcher retains its pre-specification state, preventing attackers from determining whether the speculative path trained, corrupted, or replaced main prefetcher entries through subsequent state detection.
[0073] Compared to invisible speculative caching schemes such as InvisiSpec, MuonTrap, and GhostMinion, the scope of protection of this invention is further extended to requests automatically generated by the hardware prefetcher and their training metadata. Speculative prefetch return data enters a speculative prefetch buffer with speculative tags from the moment it is generated, without updating the occupancy, replacement, or consistency status of the main cache; simultaneously, training feedback is not directly written to the main prefetcher. Therefore, this invention does not only isolate the cache for ordinary speculative loading, but also provides collaborative isolation for the "prefetch data path" and the "prefetcher training path."
[0074] Compared to the Secure Prefetching for Secure Cache Systems proposed by Nath et al. at MICRO 2024, both address the issue of degraded prefetching timeliness in secure caching systems, but their technical approaches differ. This existing solution maintains GhostMinion's commit-time prefetching principle, filters redundant cache updates during commit using SUF, and compensates for commit-late prefetching by recording memory access time information during the speculation phase and completing training and triggering during the commit phase using TSB.
[0075] This invention allows prefetch requests whose address sources meet security conditions to be issued to the next lower storage level before the branch is fully resolved or the relevant instructions have been committed, and restricts the returned data to the speculative prefetch buffer. Simultaneously, stride, confidence, and replacement state updates are restricted to the shadow prefetch training engine. Only when the reordering buffer confirms the commit and the safe merge condition is met are the data and training state merged into the target cache and the main prefetcher, respectively. Therefore, this invention does not compensate for post-commit triggering by increasing the prefetch distance, but rather preserves the actual physical memory access time through a mechanism of "early issuance during speculation, dual-path isolation before commit, and unified merging during commit."
[0076] Specifically, this invention differs from the aforementioned MICRO 2024 scheme in at least the following ways: First, the actual launch time of the prefetch request can be before the commit; second, a speculative prefetch buffer, independent of the main cache visibility state, is set for the prefetch returned data; third, independent shadow training structures are set for the prefetcher stride, confidence level, and replacement state; fourth, requests that can be launched early, are pending verification, and are prohibited from being launched are distinguished based on address dependency, execution domain, and security attributes. These differences enable this invention to simultaneously cover cache signal amplification and prefetcher metadata corruption caused by speculative prefetching, rather than simply optimizing the timeliness of prefetching at commit time.
[0077] In summary, this invention isolates data traces through a speculative prefetch buffer, isolates prefetcher metadata through a shadow prefetch training engine, unifies commit and rollback processing through a commit merging controller, and distinguishes between requests that can be issued early and those that must be delayed through a security-sensitive prefetch filter, thus forming a systematic defense architecture for speculative prefetching. This architecture can cover two types of threats: buffer side-channel signal amplification and prefetcher state corruption, while preserving the performance advantages of hardware prefetchers as much as possible while ensuring security.
[0078] The embodiments described above provide a detailed explanation of the technical solutions and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the present invention. Any modifications, additions, and equivalent substitutions made within the scope of the principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A microarchitecture side-channel attack defense method supporting speculative prefetching, characterized in that, The method, applied to a processor system including an out-of-order execution pipeline, a reordering buffer, a load-memory queue, at least one level of data cache, and a hardware prefetcher, comprises: During speculative execution, speculative tags are attached to prefetch requests generated by load instructions, prefetch instructions, or hardware prefetchers. Based on the speculative tag, determine whether the prefetch request is in a speculative path that has not yet been submitted, and redirect the prefetch request in the speculative path to a speculative prefetch buffer that is independent of the global cache level. The prefetcher training feedback, stride update, confidence update and candidate prefetch address learning results generated during the speculation period are redirected to the shadow prefetch training engine instead of directly modifying the prediction entries of the master prefetcher. When the corresponding speculative path is verified to be correct and the relevant instructions reach the submission stage, the data buffer entries in the speculative prefetch buffer that meet the safe merging conditions are written into the target cache level, and the training states in the shadow prefetch training engine that meet the submission conditions are merged into the main prefetcher. When the corresponding speculative path is rolled back, an exception occurs, it is interrupted, or its prefetch visibility classification does not meet the merging conditions, the data buffer entries in the speculative prefetch buffer and the training state in the shadow prefetch training engine are discarded, thereby preventing the prefetch behavior during speculative execution from changing the microarchitectural state that can be observed by other execution contexts.
2. The microarchitecture side-channel attack defense method supporting speculative prefetching according to claim 1, characterized in that, The speculative label includes at least one or more of the following: branch speculative identifier, reorder buffer number, branch mask, load queue number, hardware thread identifier, address space identifier, privilege level identifier, security domain identifier, source prefetcher identifier, and prefetch visibility classification, used to restrict the propagation of speculative prefetch data and shadow training state between different security domains.
3. The microarchitecture side-channel attack defense method supporting speculative prefetching according to claim 1, characterized in that, The speculative prefetch buffer includes multiple data buffer entries, each of which includes at least a valid bit, a physical address or address digest, cache line data, a data ready bit, a speculative tag, a security domain identifier, a cache hierarchy target bit, a source prefetcher identifier, and an evictation status bit.
4. The microarchitecture side-channel attack defense method supporting speculative prefetching according to claim 1, characterized in that, The speculative prefetch buffer does not participate in the shared state propagation in the processor global cache coherence protocol, does not update the main cache replacement state, does not expose the hit state to other hardware threads, and only allows access to its entries by requests carrying the same speculative label or those that have been submitted and verified.
5. The microarchitecture side-channel attack defense method supporting speculative prefetching according to claim 1, characterized in that, The shadow prefetch training engine includes a shadow history table, a shadow stride field, a shadow confidence field, and a shadow replacement status field. The shadow prefetch training engine uses the same or compatible indexing method as the main prefetcher, but its update results are physically isolated from the main prefetcher before submission.
6. The microarchitecture side-channel attack defense method supporting speculative prefetching according to claim 1, characterized in that, The secure merging conditions include: the load instruction, prefetch instruction, or hardware prefetcher-related triggering event that generated or triggered the prefetch request has been submitted or verified; the address of the prefetch request does not depend on the rolled-back transient data; the security domain identifier of the prefetch request is consistent with the currently submitted security domain identifier; and the prefetch data has not been marked as propagating across permissions, processes, or security domains.
7. The microarchitecture side-channel attack defense method supporting speculative prefetching according to claim 1, characterized in that, When a speculative path is committed, the data buffer entries in the speculative prefetch buffer are batch merged according to the reordered buffer sequence number, address conflict relationship, and cache hierarchy target bit. If the same cache line already exists in the target cache, only the data readiness status or prefetch usefulness statistics that can be safely updated are updated, without writing the cache line again.
8. The microarchitecture side-channel attack defense method supporting speculative prefetching according to claim 1, characterized in that, When the speculative path is rolled back, the speculative prefetch buffer clears the corresponding entries according to the branch speculative identifier, the shadow prefetch training engine cancels the corresponding training updates according to the same branch speculative identifier, and keeps the main prefetcher in the state before the speculative path started.
9. The microarchitecture side-channel attack defense method supporting speculative prefetching according to claim 1, characterized in that, The hardware prefetcher includes an instruction pointer stride prefetcher, a data stream prefetcher, an adjacent row prefetcher, a spatial prefetcher, a correlation prefetcher, or a combination thereof; a shadow training structure or a shared shadow training structure is configured for different hardware prefetchers.
10. The microarchitecture side-channel attack defense method supporting speculative prefetching according to claim 1, characterized in that, The speculative prefetch buffer is configured as a fully associative, set-associative, or direct mapping structure, with 8 to 128 entries, and prioritizes the elimination of entries that are invalid, merged, whose corresponding branches have been rolled back, or whose prefetch usefulness is below a threshold. The shadow prefetching training engine performs mirror calculations on the training feedback of the main prefetcher. The training feedback includes at least the previous access address, the current access stride, the predicted stride, the confidence increase or decrease, the predicted hit state, and the replacement candidate state.