A processor verification method and apparatus

Abstract

Embodiments of the present application provide a processor verification method and device, the method comprising: establishing a sub-model of each micro-architecture component in a processor memory access module, each sub-model taking a memory access operation as input and outputting a memory access result corresponding to the micro-architecture component; combining a plurality of sub-models according to a data flow relationship between the plurality of micro-architecture components to obtain a memory access model corresponding to the memory access module; inputting a set of memory access operations to the memory access model to cause the memory access model to output a data storage state of each micro-architecture component, the set of memory access operations being used to store first data to a first memory address; inputting a read operation to the memory access model to cause the memory access model to output third data based on the data storage state, the read operation being used to read second data based on a second memory address; and verifying whether the third data includes the first data.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically to a method and apparatus for processor verification. Background Technology

[0002] Currently, processors employ several hardware mechanisms to enhance performance, with three key types: branch prediction, out-of-order execution, and partial comparison. Partial comparison refers to the practice where some processors, under certain conditions—such as faulting or assisting load instructions—do not read data based on the entire memory address, but rather on a portion of the memory address (e.g., the lower six bits or the page offset). This means that only a partial address comparison is performed during data reading. This mechanism leads to microarchitectural data sampling (MDS) vulnerabilities, which attackers can exploit to steal confidential information. Currently, there are no effective detection methods for MDS vulnerabilities. Summary of the Invention

[0003] The embodiments of this application aim to provide a more effective processor verification method to detect MDS-type vulnerabilities more conveniently and completely.

[0004] To achieve the above objectives, a first aspect of this application provides a processor verification method, characterized in that the method includes: establishing sub-models corresponding to each microarchitecture component in a processor memory access module, each sub-model taking a memory access operation as input and a memory access result as output, the memory access result being the state of the microarchitecture component corresponding to the memory access operation; combining the multiple sub-models according to the data flow relationship between the multiple microarchitecture components to obtain a memory access model corresponding to the memory access module; inputting a set of memory access operations into the memory access model, causing the memory access model to output the data storage state of each microarchitecture component, the set of memory access operations being used to store first data in a first memory address; inputting a read operation into the memory access model, causing the memory access model to output third data based on the data storage state, the read operation being used to read second data based on a second memory address; and verifying whether the third data includes the first data.

[0005] By establishing sub-models for each microarchitecture component in the processor's memory access module, combining multiple sub-models into a memory access model based on the data flow relationships between these components, and then using the memory access model for formal verification, it is possible to correctly and completely detect potential MDS vulnerabilities within the processor. This approach is convenient and scalable, and can be applied to verifying MDS vulnerabilities under different instruction-level architectures and microarchitecture backgrounds.

[0006] In one embodiment of the first aspect, the data storage state includes: a first component among the plurality of microarchitecture components stores the first data; a read operation is input to the memory access model, causing the memory access model to output third data based on the data storage state; and the memory access model obtains the first data from the data storage state as the third data according to the read operation.

[0007] By outputting the first data based on the read operation from the memory access model, the presence of an MDS vulnerability in the processor can be verified based on the output of this model, and this set of memory access and read operations can be used as a counterexample leading to the MDS vulnerability.

[0008] In one embodiment of the first aspect, the first memory address and the second memory address belong to two different page types among a set of preset page types.

[0009] By dividing memory addresses into a limited number of page types and using addresses of different page types to verify the memory access model, the size of the state space of the memory access model is reduced, and the entire address space supported by the processor microarchitecture can be easily verified.

[0010] In one embodiment of the first aspect, the multiple page types are determined based on at least one of the following: access permissions, page address specification, and page caching strategy. By setting page types based on access permissions, page address specification, and page caching strategy, pages with the same characteristics can be set to the same page type, reducing the state space of the memory access model.

[0011] In one embodiment of the first aspect, the first memory address and the second memory address have the same number of bits at the end, the preset number being determined based on the address matching method of the plurality of microarchitecture components. By setting the offset relationship between the first memory address and the second memory address according to the design of the processor data path, the size of the state space of the memory access model can be reduced.

[0012] In one embodiment of the first aspect, the third data includes memory access results in cases of abnormal reads or auxiliary reads.

[0013] In one embodiment of the first aspect, the set of memory access operations includes a storage operation and a completion operation, or the set of memory access operations includes a storage operation, a completion operation, and a clear operation.

[0014] In one embodiment of the first aspect, the first memory address includes a first page type identifier, the first data is the first page type identifier, and the verification of whether the third data includes the first data involves: obtaining the first page type identifier from the first memory address and verifying whether the third data includes the first page type identifier. When the first memory address and the second memory address have different page types, by verifying whether the read data is of the page type of the first memory address, it is possible to store only the page type of the first memory address. During verification, the first page type identifier can be directly obtained from the first memory address without needing to store it separately. Furthermore, this reduces the size of the state space of the memory access module and speeds up the verification process.

[0015] A second aspect of this application provides a processor verification apparatus, the apparatus comprising: a building unit, configured to build sub-models corresponding to each microarchitecture component in a processor memory access module, each sub-model taking a memory access operation as input and a memory access result as output, the memory access result being the state of the microarchitecture component corresponding to the memory access operation; a combining unit, configured to combine the multiple sub-models according to the data flow relationship between the multiple microarchitecture components to obtain a memory access model corresponding to the memory access module; an input unit, configured to input a set of memory access operations into the memory access model, such that the memory access model outputs the data storage state of each microarchitecture component, the set of memory access operations being used to store first data in a first memory address; inputting a read operation into the memory access model, such that the memory access model outputs third data based on the data storage state, the read operation being used to read the second data based on a second memory address; and a verification unit, configured to verify whether the third data includes the first data.

[0016] A third aspect of this application provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0017] A fourth aspect of this application provides a computing device including a memory and a processor, wherein the memory stores a computer program or instructions, and the processor, when executing the computer program or instructions, implements the method described in the first aspect. Attached Figure Description

[0018] The embodiments of this application will become clearer by describing them in conjunction with the accompanying drawings:

[0019] Figure 1 A structural diagram of a computing device provided in one embodiment;

[0020] Figure 2 This is a schematic diagram of the microarchitecture in a memory access module in one embodiment;

[0021] Figure 3 A flowchart of the processor verification method provided in the embodiments of this application;

[0022] Figure 4 This is an architectural diagram of a processor verification device provided in an embodiment of this application. Detailed Implementation

[0023] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0024] Figure 1 This is a structural diagram of a computing device provided in one embodiment. Figure 1 As shown, the computing device includes a processor 10 and a memory 20. In the computing device, the processor 10 typically executes code stored in the memory 20 to perform various calculations or implement various functions, such as high-performance computing (HPC) and communication with other computing devices. The processor 10 is, for example, a central processing unit (CPU), and the memory 20 is, for example, memory. It is understood that the processor described in this embodiment can be other processors, such as a graphics processing unit (GPU). Specifically, the CPU can be connected to the memory via an external bus to read data from or write data to the memory. It is understood that in the computing device, the processor is also connected to multiple units via an external bus, such as permanent storage media, various hardware devices, etc. Figure 1 Not shown in the image.

[0025] A CPU may include one or more processing cores. Figure 1The diagram illustrates a processing core, which may include at least a front end 11, an execution unit 12, and a memory unit 13. The front end 11 is used for operations such as instruction fetching and decoding instructions into micro-instructions within the processor. Specifically, the front end 11 may include an instruction fetch unit and a decoding unit. The instruction fetch unit fetches instructions from the L2 cache in the memory unit and provides them to the decoding unit. The decoding unit decodes the fetched instructions, converting them into multiple micro-operations (uops) that can be processed by the execution unit 12, and stores these micro-instructions in the micro-instruction queue of the memory unit.

[0026] The execution module 12 includes an arithmetic and logic unit (ALU) and registers, so that the ALU in the execution module 12 can sequentially retrieve microinstructions from the microinstruction queue and execute the multiple microinstructions sequentially to perform memory access or various operations.

[0027] The processing core can have a microarchitecture that is used to implement a specific instruction set architecture (ISA). Figure 2 This is a schematic diagram of the microarchitecture of memory access module 13 in one embodiment. For example... Figure 2 As shown, the memory access module may include a store buffer (SB) 131, a level 1 data cache (L1DCache) 132, a line fill buffer (LFB) 133, and a load buffer (LB) 134. The registers in the execution module 12 can be connected to the internal bus... Figure 2 Multiple buffers (e.g., SB131, L1DCache132, and LB 134) are interconnected. Figure 2 The various buffers in the system can be interconnected via an internal bus. Figure 2 The arrows and dashed lines in the diagram illustrate the data flow when the execution module 12 executes the microinstruction corresponding to the memory access instruction. Specifically, arrows indicate possible data flow when storing data at a memory address, and dashed lines indicate possible data flow when reading data from a memory address.

[0028] Memory access instructions can include Store, Load, and Flush instructions. The Store instruction stores data from a register into memory, the Load instruction loads data from memory into a register, and the Flush instruction clears data from the cache. The corresponding microinstructions for these memory access instructions can include: Store uop, Retire uop, Flush uop, and Load uop.

[0029] Specifically, assuming that front-end 11 first fetches a Store instruction during instruction fetching, the Store instruction includes, for example, the data to be written to memory and the memory address (e.g., addr1) to which the data is to be written. After fetching the Store instruction, front-end 11 can generate a micro-instruction: Store uop, and add Retire uop to this micro-instruction, storing these two micro-instructions sequentially in the micro-instruction queue. The Retire uop can be used to return the completion information of the Store uop. The Store uop includes, for example, the data to be written to memory and the memory address addr1 to which the data is to be written, while the Retire uop includes the memory address addr1 of the data to be completed. Next, front-end 11 fetches a Flush instruction, which includes, for example, the memory address addr1 of the data to be cleared. Front-end 11 can generate a Flush uop based on the Flush instruction and store this micro-instruction sequentially in the micro-instruction queue. The Flush uop includes, for example, the memory address addr1 of the data to be cleared. Execution module 12 can fetch and execute these three micro-instructions sequentially from the micro-instruction queue.

[0030] like Figure 2As shown, when execution module 12 executes a Store uop, it determines the address in SB131 (e.g., addr2) based on the correspondence between addr1 and the addresses in SB131, and writes the data in the Store uop to address addr2 in SB131. When execution module 12 executes a Retire uop, it sends the Retire uop to SB131. The Retire uop includes the memory address addr1 of the data to be processed. Assuming address addr1 is a cache-writable address type, SB131 can read and delete data based on address addr2 of the Retire uop in SB131, determine the address addr3 in L1D Cache132 corresponding to address addr1, and store the data in address addr3 of L1D Cache132 via the internal bus, and then return the Store uop completion information to execution module 12. In another example, assuming address addr1 is a cache-non-writable address type, such as... Figure 2 As shown, SB131 can read and delete data at address addr2 in SB131, determine the address in LFB 133 corresponding to address addr1, store the data in LFB 133, and then return the Store uop completion information to execution module 12.

[0031] When data is stored in L1D Cache 132, it will be stored in L2 Cache under preset conditions (e.g., L1D Cache 132 is full and the data has been accessed infrequently). Similarly, L2 Cache will be stored in L3 Cache under preset conditions, and L3 Cache will be stored in main memory under preset conditions. For different processors, L2 Cache and L3 Cache can be located internally or externally to the processor. Similarly, data in LFB 133 can also be stored in main memory when preset conditions are met.

[0032] After executing the Retire uop, the execution module 12 can execute the Flush uop. This Flush uop includes, for example, the memory address addr1 of the data to be cleared. The execution module 12 sends the Flush uop to the L1D Cache 132. Based on the Flush uop, the L1D Cache 132 determines the address addr3 corresponding to address addr1 in the L1D Cache 132, reads and deletes the data from address addr3, determines the address addr4 in LFB 133 corresponding to address addr1, and stores the data in address addr4 of LFB 133.

[0033] Similarly, after receiving the Load instruction, front-end 11 can generate, for example, the following microinstruction: Load uop. Load uop includes, for example, the memory address addr1 of the data to be read. When executing Load uop, execution module 12 writes Load uop into LB 134. Based on Load uop, LB 134 first calculates the address addr2 in SB131 corresponding to addr1, reads data from addr2 in SB131, and if a cache hit occurs, the data can be returned to a register. If a cache miss occurs, LB 134 calculates the address in the L1D Cache corresponding to addr1, reads data from the L1D Cache, and if a cache miss still occurs, LB 134 can calculate the address in LFB 133 corresponding to addr1 and read data from LFB 133.

[0034] Under normal execution of commands as described above, the processor will produce a correct and unique processing result. However, in pursuit of high performance, processor designers have introduced numerous hardware units within the processor. These units, along with certain hardware mechanisms, can significantly enhance processor performance. Three particularly important hardware mechanisms include branch prediction, out-of-order execution, and partial comparison. However, these three mechanisms may lead to a series of exploitable microarchitectural vulnerabilities, posing a threat to processor security.

[0035] Branch prediction refers to the process where, when program execution encounters a branch but the conditions for the branch jump require multiple instruction cycles to obtain, branch prediction uses the branch predictor within the processor's microarchitecture to predict the branch jump, thus preventing pipeline congestion. The program then jumps to the predicted branch and executes it ahead of time. If a branch prediction error is detected, the processor will perform a rollback operation, flushing the pipeline and undoing any modifications to registers made by the corresponding instruction. However, the processor's rollback operation does not revert the state of the cache and some internal buffers, which provides an opportunity for attackers.

[0036] Out-of-order execution is a technique employed by processors that allows multiple instructions to be sent to their respective arithmetic units out of the program's prescribed order. Memory access instructions and operations often require multiple clock cycles. To prevent the pipeline from stalling due to such instructions, the processor prioritizes executing subsequent, data-independent instructions. When an error occurs in these out-of-order execution instructions, the handling is roughly the same as for branch prediction errors; the processor performs a rollback. However, this leaves execution traces at the microarchitectural level, providing opportunities for attackers.

[0037] Due to the temporal locality of data, data generated by a previous microinstruction may be reused by subsequent microinstructions. For example, a processor might execute a Load uop to read data from SB 131, L1D Cache 132, or LFB 133. In certain situations, such as when executing a faulting Load instruction or an assisted Load instruction, some processors do not read data based on the full memory address, but rather on a portion of the memory address (e.g., the lower six bits, or the offset within the page). This means that only a partial address comparison is performed during data reading. This reading mechanism could be exploited by attackers to steal confidential information. Faulting Load instructions trigger instruction-level exceptions, specifically general protection caused by non-standard addresses (NC) and page faults caused by insufficient page access permissions. Assisted Load instructions refer to the processor executing a different internal path during the execution of a Load instruction.

[0038] MDS vulnerability attacks and various variants have emerged in response to the aforementioned partial comparison mechanisms. MDS vulnerabilities are characterized by their stealth and difficulty in detection. Traditional verification methods, such as manual and random testing, have limitations in terms of automated detection and coverage of all vulnerabilities, failing to fundamentally solve the problem. MDS vulnerabilities can leak data passing through any internal buffer of the memory access system, including private data in the secure area. Discovered processor vulnerabilities related to out-of-order execution and predictive execution mechanisms (Spectre and Meltdown types) are generally only related to the cache in the memory access system. One related technique uses formal analysis based on out-of-order execution and predictive execution mechanisms to predict processor vulnerabilities. However, this approach does not define the formal semantics of partial comparisons, making it unable to detect or verify MDS vulnerabilities. Another related technique models the cache using formal verification methods to predict side-channel attack vulnerabilities against the cache. This technique only models the cache and cannot predict data leaks caused by other buffers within the processor, thus it still cannot be used to detect or verify MDS vulnerabilities.

[0039] In this embodiment of the application, by establishing a memory access model of the processor based on multiple microarchitecture components in the processor memory access module, and performing formal verification based on the memory access model, it is possible to correctly and completely detect MDS-type vulnerabilities that may exist inside the processor.

[0040] Figure 3 This is a flowchart of a processor verification method provided in an embodiment of this application, which can be executed by any computing device.

[0041] refer to Figure 3First, in step S301, sub-models corresponding to each microarchitecture component in the processor memory access module are established.

[0042] like Figure 2 As shown, the memory access module 13 may include microarchitectural components such as SB 131, L1D Cache 132, LFB 133, and LB 134. Therefore, sub-models can be built for each of these microarchitectural components. These sub-models can take various forms such as formulas, text, and diagrams, and are used to output memory access results based on the memory access operations input to the sub-model (corresponding to the micro-instructions used for memory access). In other words, the sub-model is a state machine corresponding to the microarchitectural component, outputting different states of the microarchitectural component based on different input memory access operations. The process of building a sub-model is also the process of building the state space of the microarchitectural component.

[0043] The memory access operation includes the operation type and the access address, where the access address can be a memory address.

[0044] Operation types include store operations, complete operations, clear operations, and read operations, which correspond to Storeop, Retireop, Flusheop, and Loadop, respectively. Clearly, different operation types will result in different output states from the memory access model.

[0045] Pages corresponding to different memory addresses have different characteristics, such as different page access permissions, page address specifications, and page caching strategies.

[0046] Page access permissions include various characteristics related to page access control, such as whether the page address is readable, writable, and whether user-mode access is allowed. For example, a page may have the following page access permission characteristics: Present: 0, P: 0; User / Supervisor: 0, US: 0; Access: 0, A: 0; and Memory protection key: 0, PK: 0.

[0047] Page address specifications include various characteristics related to page addresses, including whether the page address is a canonical address or a reserved address. For example, a page can have the following page address specification characteristics: non-canonical (NC) address, normal address, etc.

[0048] Page caching strategies include characteristics related to the page's memory address and cache interactions, such as whether the page address is allowed to be cached, whether dirty cache pages are promptly written back upon access, and whether they exhibit write-through characteristics. For example, a page can have the following characteristics: Write Back (WB), Write Through (WT), Write Combine (WC), and Uncached (UC). WB indicates that after data is written to the cache, it is not immediately written to memory, but rather at an appropriate time (e.g., when the cache is full). WT indicates that after each write to the cache, a corresponding write is made to memory to ensure cache-memory consistency. WC indicates that the corresponding data is not written to the cache, but instead written to a write combiner buffer for data merging before being written to memory. UC indicates that data is not written to the cache.

[0049] Because pages corresponding to different memory addresses have different characteristics, different page addresses will have different effects on memory access operations in the processor. In other words, different page addresses may lead to different output states in the memory access model. Specifically, different memory addresses may cause the processor's front-end (FLP) to decode instructions (such as Store instructions) into different microinstructions. For example, if the page is of type WT, the data needs to be written to the cache, while if the page is of type UC, the data is not written to the cache.

[0050] Furthermore, in cases of abnormal or auxiliary reads, due to the processor's internal comparison mechanism, different page offsets at different memory addresses may lead to different output states from the memory access model. Specifically, depending on the processor's data path design, data may be read from a reference address that is different from the requested read address in any of the following offset scenarios: the requested read address and the reference address have the same last 12 bits; the requested read address and the reference address have different last 12 bits, but the last 6 bits are the same; or the requested read address and the reference address have different last 6 bits.

[0051] Based on the above, and considering the impact of different memory addresses on memory access operations within the processor, the memory address space can be divided into a preset number of abstract addresses. Each abstract address has the same characteristics in the target processor's memory access module and can therefore be considered the same address. Then, for a specific microarchitecture module, the state of the microarchitecture component relative to various abstract addresses can be determined under multiple operation types input to the microarchitecture module, thereby generating a more complete sub-model state machine. This abstract address can include page type and page offset method. The page type can be divided according to page access permissions, page address specifications, and page caching strategies. For example, 10 page types can be set. These 10 page types may include, for example, the following page types: P:0_US:0_PK:0, A:0_WB, NC:0… The page offset method may include, for example, the three offset methods mentioned above. Therefore, a total of 10*3=30 address types can be set.

[0052] Specifically, during the establishment of the sub-model, 30 access addresses can be set, each being an instance of one of the aforementioned 30 address types. For example, the 30 access addresses could include the following: 0000 000000 000000, 0000000111 0000000, 0000 000000 000111, 0001 000000 000000, 0001 0001 000000, 0001000000 000111… The first four bits of these addresses represent the page type; for example, “0000” represents page type 0, “0001” represents page type 1, and the last 12 bits represent the offset address within the page. Assuming the page offset address of the reference address used to detect MDS vulnerabilities is "000000 000000", then in the above access address, "000000 000000" indicates the same offset as the last 12 bits of the reference address, "000111 000000" indicates the same offset as the last 6 bits of the reference address, and "000000 000111" indicates a different offset from the last 6 bits of the reference address. It is understood that this embodiment of the application exemplarily divides the memory address space into 30 address types. This embodiment of the application is not limited to this, and can divide the memory address space into more or fewer address types according to the precision requirements of the sub-model state space.

[0053] By defining abstract memory addresses as described above, the memory address space is divided into a limited number of address types, which reduces the size of the system's (sub-model or memory access model) state space. At the same time, a more complete sub-model state space can be established.

[0054] After setting the access address to a preset number of abstract addresses as described above, the state corresponding to each operation type and each abstract address can be determined for each microarchitecture module. Specifically, when modeling microarchitecture components, it is necessary to determine whether all types of abstract addresses can be read and written, and whether errors, exceptions, interrupts, or microcode interference will occur at the memory address, thereby triggering control flow interruptions and causing abnormal data paths for the processor under special circumstances.

[0055] For example, refer to Figure 2 For SB 131, the input operation types include Store type and Retire type. Therefore, the sub-model of SB 131 can include the operation results of the aforementioned 30 abstract addresses under Store operation and the operation results of the aforementioned 30 abstract addresses under Retire operation. In one embodiment, since the access address in Store uop is used as the reference address for subsequent verification Load operation, the sub-model of SB 131 can also only include the operation results of 10 abstract addresses under Store operation and the operation results of the aforementioned 10 abstract addresses under Retire operation. The page offset address of these 10 abstract addresses is set to "000000 000000", and the page type of these 10 abstract addresses is one of the aforementioned 10 page types.

[0056] For example, for the address "0000 000000 000000", the state corresponding to the Store operation operating on this address is: store the data requested to be stored in the Store operation at the address corresponding to "0000 000000 000000" in SB 131. The requested data can be "0000 000000 000000", that is, the same as the accessed address, to further reduce the state space of the sub-model. Meanwhile, assuming that the page corresponding to the address "0000 000000 000000" includes WB or WT features in its characteristics, the state corresponding to the Retire operation operating on this address is: read and delete the data in SB 131, and send the data and the Retire operation to L1D Cache 132. Assuming that the page corresponding to address “0001 000000 000000” has UC or WC characteristics, the state corresponding to the Retire operation on this address is: read and delete data in SB 131, and send the data and Retire operation to LFB 133.

[0057] Continue to refer to Figure 2For LB 134, the input operation type for LB 134 includes Load type. Therefore, the sub-model of LB 134 can include the operation results of the above 30 abstract addresses under Load operation. Specifically, the above 30 abstract addresses can be read, and the reading result can be used as the output result of the sub-model, thereby obtaining the state space of the LB 134 sub-model.

[0058] Additionally, for L1D Cache 132, the input operation types include Retire and Flush. Therefore, the sub-model of L1D Cache 132 can include the operation results of different abstract addresses under Retire operations, as well as the operation results of different abstract addresses under Flush operations. Specifically, the operation result of a specific abstract address under Retire operations could be that the data corresponding to the Retire operation is stored in the L1D Cache 132 at the address corresponding to that abstract address. The operation result of a specific abstract address under Flush operations could be that data is read from and deleted from the address corresponding to that abstract address in L1D Cache 132, and then sent to LFB 133 along with the Flush uop.

[0059] For LFB 133, the input operation types include Retire and Flush. Therefore, the sub-model of LFB 133 can include the operation results of different abstract addresses under the Retire operation, and the operation results of different abstract addresses under the Flush operation. Specifically, the operation result of a Retire operation on a specific abstract address can be that the data corresponding to the Retire operation is stored in the LFB 133 at the address corresponding to that abstract address. Similarly, the operation result of a Flush operation on a specific abstract address can be that the data corresponding to the Flush operation is stored in the LFB 133 at the address corresponding to that abstract address.

[0060] In step S302, multiple sub-models are combined to obtain the memory access model.

[0061] refer to Figure 2 The data flow relationship between microarchitecture components under different memory access microinstructions can be shown by the arrows and dashed lines in Figure 2. The sub-models corresponding to each microarchitecture component can be combined according to the data flow relationship to obtain the complete memory access model of the memory access module.

[0062] Specifically, according to Figure 2The data flow relationship shown is such that, in the state corresponding to the Retire operation in the memory access model, the SB131 sub-model is connected to the L1D Cache 132 sub-model and the LFB 133 sub-model. Therefore, when a Retire operation is input into the memory access model, the state change of the SB131 sub-model leads to the state change of the L1D Cache 132 sub-model or the LFB 133 sub-model. The memory access result after the Retire operation is input into the memory access model includes the state change of the SB131 sub-model, the state change of the L1D Cache 132 sub-model or the LFB 133 sub-model.

[0063] In the state corresponding to the Flush operation in the memory access model, the L1D Cache 132 sub-model is connected to the LFB 133 sub-model. Thus, when a Flush operation is input to the memory access model, the state change of the L1D Cache 132 sub-model causes the state change of the LFB 133 sub-model.

[0064] In the state corresponding to the Load operation in the memory access model, the LB 134 sub-model connects to the SB 131 sub-model, L1DCache132 sub-model, and LFB 133 sub-model, thereby returning read data based on the storage state of the SB 131 sub-model, L1D Cache 132 sub-model, and LFB133 sub-model.

[0065] In step S303, a set of memory access operations are sequentially input into the memory access model.

[0066] The set of memory access operations is used, for example, to store the first data at a first memory address, which is also a reference address. After inputting the set of memory access operations into the memory access model, the memory access model can output the data storage status of each of the microarchitecture components. As mentioned above, the first memory address is, for example, 0000 000000 000000, and the first data is, for example, 0000 000000 000000.

[0067] Specifically, in one implementation, the group of memory access operations may include only one storage operation, for example, the specific form of which is "Store 0000 000000 000000". After inputting this storage operation into the memory access model, the resulting state (i.e., the model output) is: the data "0000 000000 000000" is stored in SB 131 at the address corresponding to memory address "0000000000 000000". The first four bits of this memory address, for example, represent one of the aforementioned 10 page types.

[0068] In another implementation, the group of memory access operations may include 10 storage operations corresponding to the aforementioned 10 abstract addresses, which are used to store data as data at each abstract address. Each of the 10 abstract addresses includes one of 10 page types, and all have an offset address of "000000 000000".

[0069] Specifically, this group of memory access operations may include:

[0070] Store 0000 000000 000000

[0071] Store 0001 000000 000000

[0072] Store 0010 000000 000000

[0073] …

[0074] Store 1001 000000 000000,

[0075] After the 10 memory access operations are sequentially input into the memory access model, the output state is: the 10 different addresses in SB 131 are sequentially stored as the data to be stored.

[0076] In another implementation, the group of memory access operations may include:

[0077] Store 0000 000000 000000

[0078] Retire 0000 000000 000000,

[0079] Assuming page type "0000" includes WB or WT features, the state corresponding to the sequential input of this group of memory access operations into the memory access model is as follows: store the data "0000 000000 000000" into SB 131 at the address corresponding to memory address "0000 000000 000000", and then move the data "0000 000000 000000" in SB 131 into L1D Cache 132 at the address corresponding to memory address "0000 000000 000000". Assuming page type "0000" includes WC or UC characteristics, the state corresponding to the input memory access operation into the memory access model is as follows: store the data "0000 000000 000000" into the address corresponding to memory address "0000 000000 000000" in SB 131, and then move the data "0000 000000 000000" in SB 131 into the address corresponding to memory address "0000 000000 000000" in LFB 133.

[0080] In another implementation, the group of memory access operations may include:

[0081] Store 0000 000000 000000

[0082] Store 0001 000000 000000

[0083] Store 0010 000000 000000

[0084] …

[0085] Store 1001 000000 000000

[0086] Retire 0000 000000 000000

[0087] Retire 0001 000000 000000

[0088] …

[0089] Retire 1001 000000 000000,

[0090] After the multiple memory access operations are sequentially input into the memory access model, the output state of the memory access model is as follows: the 10 different memory addresses are sequentially stored in the addresses corresponding to these 10 addresses in SB131 as stored data, and the 10 data stored in SB131 are sequentially moved into the addresses corresponding to each memory address in L1D Cache132 or LFB133.

[0091] In another implementation, the group of memory access operations may include:

[0092] Store 0000 000000 000000

[0093] Retire 0000 000000 000000

[0094] Flush 0000 000000 000000

[0095] Assuming page type "0000" includes WB or WT features, the state corresponding to the input memory access model for this group of memory access operations is as follows: Store the data "0000 000000 000000" into SB 131 at the address corresponding to memory address "0000 000000 000000", then move the data "0000 000000 000000" from SB 131 into L1D Cache 132 at the address corresponding to memory address "0000 000000 000000", and then move the data "0000 000000000000" from L1D Cache 132 into LFB 133 at the address corresponding to memory address "0000 000000 000000". Assuming page type "0000" includes WC or UC characteristics, the state corresponding to the input memory access operation into the memory access model is as follows: Store the data "0000000000 000000" in SB 131 at the address corresponding to memory address "0000 000000 000000", then move the data "0000 000000 000000" in SB131 to the address corresponding to memory address "0000 000000 000000" in LFB 133, and then delete the data "0000 000000 000000" stored in LFB 133.

[0096] In another implementation, the group of memory access operations may include:

[0097] Store 0000 000000 000000

[0098] Store 0001 000000 000000

[0099] Store 0010 000000 000000

[0100] …

[0101] Store 1001 000000 000000

[0102] Retire 0000 000000 000000

[0103] Retire 0001 000000 000000

[0104] …

[0105] Retire 1001 000000 000000

[0106] Flush 0000 000000 000000

[0107] Flush 0001 000000 000000

[0108] …

[0109] Flush 1001 000000 000000,

[0110] After the multiple memory access operations are sequentially input into the memory access model, the output state of the memory access model is as follows: the 10 different memory addresses are sequentially stored in SB131 and corresponding to the 10 addresses respectively; the 10 data stored in SB131 are sequentially moved into the addresses corresponding to each memory address in L1D Cache132 or LFB133; and the data stored in L1D Cache132 or LFB133 is sequentially cleared.

[0111] In step S304, the read operation is input into the memory access model, and the read result is output. In step S305, the read result is verified.

[0112] To fully verify the MDS vulnerability using the memory access model, the storage address in the aforementioned storage operation can be used as a reference address. The memory address to be read in the read operation can be set to a different memory address with any of the three offset relationships mentioned above from the reference address. Based on the state of the memory access model after inputting the above set of memory access operations, it can be verified whether data already stored or to be stored at the reference address can be read from the memory access module, thereby verifying the existence of the MDS vulnerability. The page type of the memory address in the read operation can be the same as or different from the reference address. For example, the read operation is used to read second data based on a second memory address. The second memory address is a memory address different from the first memory address mentioned above, and the second data can be the second memory address. That is, by reading second data based on a second memory address different from the reference address, it is verified whether the first data at the reference address can be read. Verifying the read result is equivalent to verifying whether the read data is the first data, thereby verifying the existence of the MDS vulnerability.

[0113] Specifically, for the above implementation where the set of memory access operations is "Store 0000 000000 000000", the read operation can be set to any of the following read operations:

[0114] LOAD 0001 000000 000000

[0115] LOAD 0010 000000 000000

[0116] …

[0117] LOAD 1001 000000 000000

[0118] Each read operation in this group verifies whether data can be read from the reference address when reading from an address with a different page type and the same last 12 bits as the reference address. When any read operation is input into the current memory access model, in the event of an abnormal or auxiliary read, and if SB 131 only matches the last 12 bits of the memory address, the SB 131 sub-model outputs the data "0000 000000 000000" stored at the address corresponding to the reference address 00000000000 000000 as the output of the memory access model. Based on the output of this memory access model, it can be concluded that data already stored or to be stored at the reference address was read from an address different from the reference address, thus indicating an MDS vulnerability. In this scenario, since the page types corresponding to each read operation are different from those corresponding to the storage operation, the data stored in the storage operation can be set to the page type of the storage address, i.e., "0000". After reading data through any of the above read operations, it is only necessary to determine whether the read data is of the page type corresponding to the reference address, thereby determining whether an MDS vulnerability exists. This reduces the amount of data that needs to be stored in the memory access module, and also reduces the amount of data in the state space of the memory access model.

[0119] For the above set of memory access operations as shown below,

[0120] Store 0000 000000 000000

[0121] Store 0001 000000 000000

[0122] Store 0010 000000 000000

[0123] …

[0124] Store 1001 000000 000000,

[0125] When any of the above read operations (e.g., LOAD 0001 000000 000000) is input into the current memory access model, in the case of abnormal or auxiliary reads, and SB 131 only matches the last 12 bits of the memory address, the SB 131 sub-model will output the data stored in the addresses corresponding to the various reference addresses 0000 000000 000000, 0010 000000000000, ... 1001 000000 000000 as the output of the memory access model. Based on the output of this memory access model, it can be concluded that data already stored or to be stored in the reference address was read through an address different from the reference address, thus indicating an MDS vulnerability.

[0126] For the above implementation where the set of memory access operations is "Store 0000 000000 000000", the read operation can also be set to any of the following read operations:

[0127] LOAD 0001 000111 000000

[0128] LOAD 0010 000111 000000

[0129] …

[0130] LOAD 1001 000111 000000

[0131] Each read operation in this group verifies whether data can be read from the reference address when reading from an address with a different page type and the same last 6 bits as the reference address. When any read operation is input into the current memory access model, in the event of an abnormal or auxiliary read, and if SB 131 only matches the last 6 bits of the memory address, the SB 131 sub-model outputs the data "0000 000000 000000" stored at the address corresponding to the reference address 0000 000000 000000 as the output of the memory access model. This can be used to determine if an MDS vulnerability exists.

[0132] For the above implementation where the set of memory access operations is "Store 0000 000000 000000", the read operation can also be set to any of the following read operations:

[0133] LOAD 0001 000000 000111

[0134] LOAD 0010 000000 000111

[0135] …

[0136] LOAD 1001 000000 000111

[0137] Each read operation in this group verifies whether data can be read from the reference address when reading from an address with a different page type and different from the last 6 bits of the reference address. When any read operation is input into the current memory access model, in the event of an abnormal read or auxiliary read, and if the SB 131 sub-model does not perform page offset matching of the memory address, the SB 131 sub-model will output the data "0000 000000 000000" stored at the address corresponding to the reference address 00000000000 000000 as the output of the memory access model. This can be used to determine the existence of an MDS vulnerability.

[0138] For the above implementation where the set of memory access operations is "Store 0000 000000 000000", the read operation can also be set to any of the following read operations:

[0139] LOAD 0000 000111 000000

[0140] LOAD 0000 000000 000111,

[0141] Each read operation in this group verifies whether data can be read from the reference address when it has the same page type as the reference address but a different offset address relative to the reference address. When any read operation is input into the current memory access model, in the event of an abnormal read or auxiliary read, and SB 131 performs matching of the last 6 bits of the memory address within the page offset address, or does not perform matching of the memory address within the page offset address, the SB 131 sub-model outputs the data "0000000000 000000" stored at the address corresponding to the reference address 0000 000000 000000 as the output of the memory access model. This can be used to determine the existence of an MDS vulnerability.

[0142] In an implementation where the memory access model has been input, the following set of memory access operations has been included:

[0143] Store 0000 000000 000000

[0144] Retire 0000 000000 000000,

[0145] The memory address in the storage operation (i.e., "000000 000000") can be used as the reference address. The memory address to be read in the read operation can be set to a different memory address that has any of the three offset relationships mentioned above with the reference address. Based on the state of the memory access model after inputting the above set of memory access operations, it can be verified whether the data that has been stored or is to be stored at the reference address can be read from the memory access module, thereby verifying whether there is an MDS vulnerability.

[0146] For example, you can input LOAD 0001 000000 000000 into the memory access model. After inputting any read operation into the current memory access model, refer to... Figure 2 The data flow relationship shown indicates that the memory access model first checks if there is a hit in the state of the SB 131 sub-model. After determining that there is no hit in the SB 131 sub-model, it checks the L1D Cache 132 sub-model. In the event of an abnormal read or auxiliary read, and if the L1D Cache 132 sub-model only matches the last 12 bits of the memory address, the L1D Cache 132 sub-model will output the data "0000 000000 000000" stored at the address corresponding to the reference address 0000 000000000000 as the output of the memory access model. Based on the output of this memory access model, it can be concluded that data already stored or to be stored at the reference address was read through an address different from the reference address, thus indicating an MDS vulnerability.

[0147] In an implementation where the memory access model has been input, the following set of memory access operations has been included:

[0148] Store 0000 000000 000000

[0149] Retire 0000 000000 000000

[0150] Flush 0000 000000 000000,

[0151] Similarly, the memory address in the storage operation (i.e., "000000 000000") can be used as the reference address, and the memory address to be read in the read operation can be set to a different memory address that has any of the three offset relationships mentioned above with the reference address. Based on the state of the memory access model after inputting the above set of memory access operations, it can be verified whether the data that has been stored or is to be stored at the reference address can be read from the memory access module, thereby verifying whether there is an MDS vulnerability.

[0152] For example, you can input LOAD 0001 000000 000000 into the memory access model. After inputting this read operation into the current memory access model, refer to... Figure 2 The data flow relationship shown indicates that the memory access model first checks if there is a cache miss in the SB 131 sub-model. If a miss is found in the SB 131 sub-model, the L1D Cache 132 sub-model is checked. If a miss is also found in the L1D Cache 132 sub-model, the LFB 133 sub-model is checked. In the event of an abnormal read or auxiliary read, and if the LFB 133 sub-model only matches the last 12 bits of the memory address, the LFB 133 sub-model will output the data "0000 000000000000" stored at the address corresponding to the reference address 0000 000000 000000 as the output of the memory access model. Based on this output, it can be concluded that data already stored or to be stored at the reference address was read through an address different from the reference address, thus indicating an MDS vulnerability.

[0153] After verifying the existence of an MDS vulnerability in the memory access model, counterexamples can be generated based on the verification results. These counterexamples are the microinstruction sequences that lead to the existence of an MDS vulnerability. If the memory access model is verified to be free of MDS vulnerabilities using the above method, it can be determined that the microinstruction sequence corresponding to the aforementioned set of memory access operations is safe, thereby verifying that the processor does not have an MDS vulnerability.

[0154] Specifically, the memory access model and validation methods described above can be written as model code, for example, using the NuSMV language. Then, any model validation tool can be used to validate the model based on this model code.

[0155] Figure 4 This application provides an architectural diagram of a processor verification device, the device comprising:

[0156] Establishment unit 41 is used to establish sub-models corresponding to each microarchitecture component included in the processor's memory access module. Each sub-model takes a memory access operation as input and a memory access result as output. The memory access result is the state of the microarchitecture component corresponding to the memory access operation.

[0157] Combination unit 42 is used to combine the multiple sub-models according to the data flow relationship between the multiple microarchitecture components to obtain the memory access model corresponding to the memory access module;

[0158] Input unit 43 is used to input a set of memory access operations into the memory access model, so that the memory access model outputs the data storage status of each of the microarchitecture components, wherein the set of memory access operations is used to store first data into a first memory address; and to input read operations into the memory access model, so that the memory access model outputs third data based on the data storage status, wherein the read operations are used to read second data based on a second memory address.

[0159] Verification unit 44 is used to verify whether the third data includes the first data.

[0160] It should be understood that the descriptions such as "first" and "second" in this article are merely for the sake of simplicity in description and to distinguish similar concepts, and do not have any other limiting function.

[0161] Those skilled in the art will clearly understand that the descriptions of the various embodiments provided in this application can be referenced to each other. For the sake of convenience and brevity, for example, the functions and execution steps of the various devices and equipment provided in the embodiments of this application can be referred to the relevant descriptions of the method embodiments of this application. The method embodiments and the device embodiments can also be referenced to each other.

[0162] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs all or part of the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as read-only memory (ROM), random-access memory (RAM), magnetic disks, or optical disks.

[0163] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium, or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0164] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways without exceeding the scope of this application. For example, the embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0165] Furthermore, the described apparatus and methods, as well as the schematic diagrams of different embodiments, can be combined or integrated with other systems, modules, technologies, or methods without departing from the scope of this application. Additionally, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through interfaces, devices, or units, and may be electronic, mechanical, or other forms.

[0166] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A processor verification method, characterized in that, The method includes: Establish sub-models corresponding to multiple microarchitecture components in the processor memory access module. Each sub-model takes a memory access operation as input and a memory access result as output. The memory access result is the state of the microarchitecture component corresponding to the memory access operation. Based on the data flow relationship between the multiple microarchitecture components, the sub-models corresponding to the multiple microarchitecture components are combined to obtain the memory access model corresponding to the memory access module. A set of memory access operations is input into the memory access model, causing the memory access model to output the data storage status of each of the microarchitecture components. The set of memory access operations is used to store the first data into the first memory address. The read operation is input into the memory access model, so that the memory access model outputs third data based on the data storage state, and the read operation is used to read the second data based on the second memory address; Verify whether the third data includes the first data.

2. The method according to claim 1, characterized in that, The first memory address and the second memory address belong to two different page types among a set of preset page types.

3. The method according to claim 2, characterized in that, The various page types are determined based on at least one of the following for memory pages: access permissions, page address specification, and page caching strategy.

4. The method according to any one of claims 1-3, characterized in that, The first memory address and the second memory address have the same number of bits at the end of a preset number of bits, which is determined based on the address matching method of the plurality of microarchitecture components.

5. The method according to claim 1, characterized in that, The third data includes memory access results in cases of abnormal reads or auxiliary reads.

6. The method according to claim 1, characterized in that, The set of memory access operations includes a storage operation and a completion operation, or the set of memory access operations includes a storage operation, a completion operation, and a clear operation.

7. The method according to claim 2, characterized in that, The first memory address includes a first page type identifier, the first data is the first page type identifier, and the step of verifying whether the third data includes the first data is to obtain the first page type identifier from the first memory address and verify whether the third data includes the first page type identifier.

8. A processor verification device, characterized in that, The device includes: A modeling unit is used to establish sub-models corresponding to multiple microarchitecture components in the processor memory access module. Each sub-model takes a memory access operation as input and a memory access result as output. The memory access result is the state of the microarchitecture component corresponding to the memory access operation. The combination unit is used to combine the sub-models corresponding to the multiple micro-architecture components according to the data flow relationship between the multiple micro-architecture components to obtain the memory access model corresponding to the memory access module. An input unit is used to input a set of memory access operations into the memory access model, so that the memory access model outputs the data storage status of each of the microarchitecture components, wherein the set of memory access operations is used to store first data into a first memory address; and to input a read operation into the memory access model, so that the memory access model outputs third data based on the data storage status, wherein the read operation is used to read second data based on a second memory address. A verification unit is used to verify whether the third data includes the first data.

9. A computer-readable storage medium having a computer program or instructions stored thereon, which, when executed in a computer, cause the computer to perform the method of any one of claims 1-7.

10. A computing device comprising a memory and a processor, wherein the memory stores a computer program or instructions, and the processor, when executing the computer program or instructions, implements the method of any one of claims 1-7.

Images