Method and microprocessor for spectre mitigation using indirect effective tables

Abstract

The present application relates to methods and microprocessors for Spectre mitigation using an indirect valid table. In one embodiment, a microprocessor comprises: a branch prediction table comprising a plurality of entries, wherein at least a portion of the plurality of entries correspond to an indirect branch type; and an indirect valid table; wherein, based on a fetch of an indirect branch instruction, an entry in the branch prediction table corresponding to the indirect branch instruction is configured to be invalidated based on a clearing of a corresponding entry in the indirect valid table.

Description

Technical Field

[0001] This invention generally relates to microprocessors, and more specifically to microprocessor security. Background Technology

[0002] In early 2018, researchers released information related to potential security vulnerabilities in microprocessors, specifically those that could allow malicious code to expose privileged data stored in computer chips (e.g., secret or private data, such as data belonging to other programs running on the microprocessor, data accessible only to administrators, etc.). Several variations of these security vulnerabilities exist, two of which are categorized under the generic label Spectre, and a third is called Meltdown. These vulnerabilities arise from the development of speculative execution and caching mechanisms used in modern microprocessors.

[0003] There are two variants of the Spectre vulnerability. The first (sometimes called boundary check bypass) involves malicious code that induces incorrect speculation in kernel mode and indirectly learns cache access patterns, thus speculatively accessing kernel memory to access privileged data. The second variant (sometimes called branch target injection) uses indirect branch prediction to trick the microprocessor into speculatively executing into memory locations it wouldn't otherwise execute. If executing these instructions leaves state in the cache that can be detected using cache inference attacks, the attacker can then access the contents of kernel memory.

[0004] Public attempts to mitigate the Spectre vulnerability include static analysis and defenses against a first variant (Variant I), and microcode updates against a second variant (Variant II) (which is the focus of this invention), employing two notable mitigation techniques: Indirect Branch Restriction Speculation (IBRS) and Indirect Branch Predictor (sometimes also called "prediction") Barrier (IBPB). IBRS prevents indirect branches in lower privilege level code from affecting predictions in higher privilege level code. IBRS has variants that also prevent higher privilege level code from affecting predictions in lower privilege level code (thus requiring accurate privilege level matching). IBPB clears the Branch Target Address Cache (BTAC) for indirect branch speculation that runs between user-mode and guest-mode context switches. Summary of the Invention

[0005] In one embodiment, a microprocessor includes: a branch prediction table comprising a plurality of entries, wherein at least a portion of the plurality of entries corresponds to an indirect branch type; and an indirect validity table; wherein, based on indirect branch instruction fetching, an entry in the branch prediction table corresponding to an indirect branch instruction is configured to be invalidated based on the clearing of the corresponding entry in the indirect validity table.

[0006] Other systems, methods, features, and advantages of the present invention will be apparent or become apparent to those skilled in the art upon examination of the following drawings and detailed description. All such additional systems, methods, features, and advantages are intended to be included within this specification, the scope of the invention, and protected by the appended claims. Attached Figure Description

[0007] The various aspects of the invention can be better understood by referring to the following accompanying drawings. The components in the drawings are not necessarily drawn to scale; rather, the focus is on clearly illustrating the principles of the invention. Furthermore, in the drawings, the same reference numerals denote corresponding parts in multiple views.

[0008] Figure 1A This is a block diagram illustrating an example branch unit pipeline used by a microprocessor to implement an embodiment of a branch prediction safety system.

[0009] Figure 1B It is shown Figure 1A The diagram shows an example front end of a branch unit pipeline.

[0010] Figure 2 This is a schematic diagram illustrating an example branch prediction security system based in part on the Indirect Branch Restriction Speculation (IBRS) mitigation technique for the Spectre Variant II vulnerability.

[0011] Figure 3 This is a schematic diagram illustrating an example branch prediction security system embodiment based in part on the Indirect Branch Predictor Barrier (IBPB) mitigation technique for the Spectre Variant II vulnerability.

[0012] Figure 4 This is a flowchart illustrating an embodiment of an example branch prediction security method based on IBRS.

[0013] Figure 5 This is a flowchart illustrating an embodiment of an example branch prediction security method based on IPB. Detailed Implementation

[0014] Some embodiments of branch prediction security systems and methods for providing Spectre mitigation based on Indirect Branch Restriction Speculation (IBRS) and Indirect Branch Predictor Barrier (IBPB) mitigation techniques for microprocessors are disclosed. IBRS prevents indirect branches in lower privilege level code from affecting predictions in higher privilege level code. IBRS also has variations in which higher privilege level code also prevents predictions in lower privilege level code from affecting predictions (e.g., thus requiring accurate privilege level matching). In one embodiment, the branch prediction security system indicates this by using two additional (2) tag bits in the prediction table (e.g., branch target address cache or BTAC) entries. IBRS is implemented using multiple (e.g., four (4)) privileged states. These two bits are referred to as the predictor mode, but their existence is not publicly disclosed in BTAC. Instead, as can be best understood, as with IBBB, when the microcode transitions to a higher privileged mode, It appears this will clear the predictor. Additional information regarding privilege levels and predictor modes can be found in the [specific section / category]. The information was found in U.S. Patent Application Publication No. 20200133679. If a branch instruction fails the privilege level test, embodiments of the branch prediction safety system render the branch instruction miss and unpredictable. The IBPB clears indirect branches when transitioning from a lower privilege code to a higher privilege code. In one embodiment, the branch prediction safety system implements the IBPB by adding a separate indirect validity table for indirect branch instructions. The indirect validity table can be cleared in a single clock cycle because all bits are cleared simultaneously. When the branch prediction table (e.g., BTAC) is read, the indirect branch instruction should have both the normal valid bits to be read as a branch instruction and the indirect valid bits. Based on the clearing of the corresponding entry in the indirect validity table, the branch prediction table is configured to be invalid.

[0015] Additionally, IBRS and IPB are two mitigation techniques used for Spectre II variants. However, implementation details have been left to individual chip manufacturers. In some cases, hardware fixes have led to performance issues, which is not surprising, as speculative processing in modern processors stems from the need for hardware-based acceleration. Furthermore, some techniques (such as IPB, where indirect branches are cleared) are not feasible for large branch prediction tables (such as BTAC). For example, a current BTAC might have four thousand (4k) entries (with multiple paths), each entry ninety (90) bits wide, where a mixture of branch types is scattered and stored. Clearing each valid bit entry (e.g., setting it to zero) for all branch entries in each cycle consumes considerable power and is wasteful. Moreover, creating a table (array) that conditionally clears valid bit entries based on type data also stored in the table without sequentially reading each entry in the table is impractical, at least in part due to the number of cycles required. Conversely, some embodiments of branch prediction safety systems circumvent these and / or other challenges by adding (predictor pattern) tags to the prediction table to enable determination of whether the current predictor pattern is equal to or greater than the predictor pattern indicated by the tag, and / or using small (e.g., multiple rows of single-bit entries in some embodiments, but may also use additional entries per row or one or more additional small tables, such as the additional entries or tables typically used in BTAC for main valid entries to achieve fast clearing) indirect valid tables to clear valid entries in a single clock cycle during transitions between supervisor and user code. Therefore, performance in terms of speed and efficiency is improved when compared to other IBRS / IBPB methods.

[0016] Having summarized certain features of the branch prediction security system of the present invention, reference will now be made in detail to the description of the branch prediction security system as illustrated in the accompanying drawings. While the branch prediction security system will be described in conjunction with these drawings, it is not intended to limit it to the one or more embodiments disclosed herein. That is, while the invention permits modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will be described in detail herein in a manner sufficient for those skilled in the art to understand. However, it should be understood that the drawings and their detailed description are not intended to limit the invention to the specific forms disclosed. Rather, the invention will cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., implying potential) rather than a mandatory sense (i.e., implying necessity). Similarly, the words “include,” “including,” and “includes” mean including but not limited to.

[0017] Various units, modules, circuits, logic, or other components can be described as being "configured" to perform one or more tasks. In this context, "configured" is a broad description of a structure, which generally means "having a circuit or other physical structure" that performs or is capable of performing one or more tasks during operation. A circuit can be a special-purpose circuit or a more general-purpose processing circuit operating under the control of coded instructions. That is, in describing certain aspects or features of various implementations of the invention, terms such as "unit," "module," "circuit," "logic," and "component" may be used herein. Those skilled in the art will understand that the corresponding features are implemented using circuits, whether those circuits are special-purpose circuits or more general-purpose circuits operating under the control of microcoded instructions.

[0018] Furthermore, units / modules / circuits / logic / components can be configured to perform tasks even when the unit / module / circuit / logic / component is not currently in operation. The description of units / modules / circuits / logic / components configured to perform one or more tasks explicitly aims to avoid functional limitations on those units / modules / circuits / logic / components. Those skilled in the art will understand that the specific structure or interconnection of circuit elements will typically be determined by the compiler of design automation tools (such as register-transfer language (RTL) compilers). RTL compilers operate on scripts that are very similar to assembly language code to compile the scripts into a form for the layout or fabrication of the final circuit.

[0019] That is, more advanced software tools are used to design integrated circuits (such as the integrated circuits of this invention) to model the desired functional operation of the circuit. As is well known, "Electronic Design Automation" (or EDA) is a category of software tools used to design electronic systems (such as integrated circuits). EDA tools are also used to program design functions into field-programmable gate arrays (FPGAs). Hardware description languages ​​(HDLs) such as Verilog and Very High Speed ​​Integrated Circuit Hardware Description Language (VHDL) are used to create a high-level representation of the circuit from which a low-level representation and the final actual wiring can be derived. In practice, since modern semiconductor chips can have billions of components, EDA tools are considered essential for their design. In practice, circuit designers use programming languages ​​such as C / C++ to specify operational functions. EDA software tools translate this specified function into RTL. The hardware description language (e.g., Verilog) then translates the RTL into a discrete gate netlist. This netlist defines the actual circuit produced, for example, by a foundry. In practice, these tools are well known and understood for their role and use in facilitating the design process of electronic and digital systems, and therefore need not be described further herein.

[0020] Figure 1AAn embodiment of an exemplary branch unit pipeline of a microprocessor 10 is shown. It should be understood that, for brevity and ease of explanation and illustration, certain known components of the microprocessor 10 are omitted herein. As is known, pipelined architectures provide multiple instructions that overlap during execution, where each stage is called a pipeline level. The blocks shown in the branch unit pipeline can each be implemented according to one or more levels, which are shown on the left side of the blocks and, in the depicted embodiment, are represented by the uppercase letters C, I, B, U, L, M, F, G, W, X, E, S, W, Y, and Z, which proceed sequentially from top to bottom and are redirected (as indicated by arrows). Those skilled in the art will understand that... Figure 1A The number and / or arrangement of stages depicted herein are merely illustrative of one exemplary embodiment, and in some embodiments, different numbers and / or arrangements of stages may be implemented, and are therefore contemplated within the scope of the invention. Those skilled in the art will also understand that the blocks provide a general description of the functionality of the branch pipeline, and for brevity, associated logic or circuitry known to those skilled in the art has been omitted herein. For example, those skilled in the art will understand that, as is known, each stage of a pipeline can be separated by a clock pipeline register or latch. As another example, although Figure 1A Although not explicitly shown, those skilled in the art should understand that operations at the front end involve data exchange or interaction with the instruction cache.

[0021] The instruction cache is a random access memory device within a microprocessor. The microprocessor loads and / or pre-fetches (e.g., from DRAM via a bus interface unit) instructions of an ISA machine language program (such as x86 ISA machine language instructions) that have recently been fetched from a larger cache (e.g., L2 cache, L3 cache) or system memory and are executed by the microprocessor during the execution of the ISA machine language program. The ISA defines an instruction address register that holds the memory address of the next ISA instruction to be executed (defined by the x86 ISA as the instruction pointer (IP), but sometimes called the program counter (PC)). The microprocessor updates the contents of the instruction address register as it runs the machine language program to control program flow. To subsequently fetch ISA instructions faster from the instruction cache rather than from system memory based on the contents of the instruction address register during the next execution of the machine language program, the ISA instructions are cached such that the register holds the memory addresses of the ISA instructions present in the instruction cache. Specifically, the instruction cache is accessed based on the memory address held in the instruction address register (e.g., IP), rather than exclusively based on the memory address specified by a load or store instruction. Therefore, a dedicated data cache that stores ISA instructions as data (such as those that may reside in the hardware portion of a system employing a software translator) and is accessed exclusively based on load / store addresses rather than through instruction address register values ​​is not an instruction cache. Furthermore, for the purposes of this invention, a unified cache that caches both instructions and data (i.e., based on both instruction address register values ​​and load / store addresses, rather than exclusively based on load / store address access) is intended to be included in the definition of an instruction cache.

[0022] Special attention Figure 1A The microprocessor 10 includes a branch unit pipeline, wherein the microprocessor 10 comprises a pipelined microprocessor, and in one embodiment, the instruction set of the pipelined microprocessor is substantially compliant with the x86 architecture instruction set. As will be appreciated by those skilled in the art from the description provided herein, the present invention can be implemented in a variety of different circuit structures and architectures, and Figure 1AThe architecture shown is just one of many suitable architectures. An exemplary microprocessor 10 includes a fast predictor 12, a branch target address cache (BTAC) 14, an instruction byte queue (XIB) 16, a branch decoder 18, a formatted instruction queue (FIQ) / circular queue 20, an instruction translator 22, a register alias table (RAT) / reservation station (RS) 24, functional units (e.g., integer units, floating-point units, etc.) 26, and a branch table update 28. The boxes of the various reference numerals in the microprocessor 10 correspond to logic implemented on corresponding multiple stages C, I, B, U, L, M, F, G, W, X, E, S, W, Y, and Z, where the pipelined architecture enables different instruction sets at each stage. In one embodiment, four or more instructions can be executed at each stage, where control signals mark each stage along the pipeline. The stages associated with the fast predictor 12, BTAC 14, and XIB 16 relate to the instruction cache (I cache, Figure 1A Access (not shown in the image).

[0023] The fast predictor 12 includes a single-cycle branch predictor that provides single-cycle prediction (e.g., taking one cycle to generate the target address, provided at level I in one embodiment). In one embodiment, the fast predictor 12 includes a table (also referred to herein as an array or target array) storing the branch target addresses of previously executed branch instructions, which performs branch prediction when the stored branch instructions are subsequently encountered. In one embodiment, the table includes 128 entries, but in some embodiments other sizes (e.g., 64 entries, 32 entries, etc.) may be used. The table is organized as an n-way (e.g., n is an integer greater than 1) set-associative cache. Generally, an n-way set-associative cache is also referred to herein as a multi-set-associative cache. In one embodiment, each entry stores eight (8) 3-bit counters and the current local branch mode, which are selected by the 3-bit local branch mode. The fast predictor 12 also includes a conditional branch predictor that is accessed in parallel with the table and provides take / not take direction for conditional branches. The fast predictor also includes a return stack that can provide targets instead of the table. In one embodiment, the return stack comprises four (4) entries and provides a target for the return instruction. Note that the specifications listed above are for illustrative purposes only, and some embodiments may be implemented under different specifications, and are therefore contemplated within the scope of the invention. The fast predictor 12 is configured to deliver the predicted branch target immediately (within a single cycle) without employing branch penalties. In some embodiments, the fast predictor 12 may operate according to other specifications of its prediction mechanism and / or table configuration, or in some embodiments, the fast predictor 12 may be omitted. Most branches are correctly predicted by the fast predictor 12. In some embodiments, where the fast predictor 12 provides a branch prediction that differs from the branch prediction of BTAC 14 (e.g., different in direction and / or target) based on the same acquired branch instruction, BTAC 14 utilizes the branch prediction information provided by BTAC 14 (e.g., direction, target address, branch prediction type) to rewrite the branch prediction of the fast predictor 12 and update the fast predictor table within a set of levels of BTAC 14 (e.g., at level U).

[0024] Level I and / or Level B correspond to access to various tables in the branch unit pipeline (including I cache, tag array, translation back buffer (TLB) array, BTAC array, return stack array, etc.), (e.g., tag-based) direction or path given by multiplexing, and read instructions.

[0025] BTAC 14 retains information related to previously executed branch instructions used to predict the target address, direction, and type during subsequent execution. BTAC 14 includes one or more tables much larger than those of the fast predictor 12. In one embodiment, BTAC 14 includes a 4k-entry, m-way set-association table (also referred to herein as an array or target array), where m is an integer greater than 1. Each entry in BTAC 14 includes a valid bit, a predicted branch target address, a predicted direction, and a branch type. In one embodiment, each entry additionally includes two tag bits, also referred to herein as predictor mode bits. As explained above, the predictor mode bits are also represented by... Four (4) different privilege states are used. The branch type specifies whether the branch instruction is a call / return, an indirect branch, a conditional relative branch, or an unconditional relative branch. In one embodiment, BTAC 14 includes a conditional relative branch predictor (or simply a conditional branch predictor) with a multi-entry (e.g., 12k) label geometry (TAGE)-based conditional branch predictor, multiple tables, multiple bits (e.g., 3 bits), a take / not take (T / NT) counter, and a multi-bit global branch history, or in conjunction with these. That is, the TAGE conditional branch predictor includes a label table with a geometrically increased branch history length, as is well known. As another example, indirect prediction includes a multi-entry (e.g., 1.5k) TAGE predictor and uses table entries for static indirect branches. In one embodiment, two TAGE conditional branch predictors are used, one for edge A of the table and one for edge B of the table. The TAGE conditional branch predictor may be part of BTAC or used in conjunction with BTAC 14.

[0026] In one embodiment, BTAC 14 includes or collaborates with a second type of conditional branch predictor (e.g., a gshare predictor associated with an edge C of a table) that has lower complexity than the TAGE conditional branch predictor. The gshare conditional branch predictor may be part of or used in conjunction with BTAC 14. The gshare conditional branch predictor comprises a complexity between that of the fast predictor 12 and the TAGE conditional branch predictor (e.g., approximately 1 / 10 the size of the TAGE conditional branch predictor). In one embodiment, the gshare conditional branch predictor includes a single table (e.g., an m-bit global history register comprising the branch patterns of the last m executed branch instructions, where m is typically 10-12 bits, but not limited to that number). The gshare conditional branch predictor uses the global branch history and the location (e.g., IP) of the branch instruction to create an index (via an XOR logical operation) into a table of counters (e.g., a 2-bit counter), where the result of the index is a prediction for the current branch. Since TAGE and gshare type conditional branch predictors are known in the art, further description thereof is omitted here for brevity. Note that in some embodiments, other types of prediction mechanisms may be used, including correlation-based prediction mechanisms, conditional branch predictors using a combination of global and local branch histories, etc. Furthermore, although edges A, B, and C are emphasized here, fewer or additional edges may be used in some embodiments. For each portion of a cache line of the instruction cache or each fetch unit (e.g., 16 bytes), BTAC 14 may maintain three entries (e.g., edges A, B, and C, although fewer edges may be used in some embodiments to store prediction information for fewer branch instructions), which may hold prediction information for up to three branch instructions that may exist in a portion of the cache line. BTAC 14 includes operation through a set of levels (e.g., level I, level B, and level U). In practice, the level U of the branch instruction is used as the level C of the target (e.g., the arrow from level B to level C reflects the branch instruction at level B, and the next clock is the level C of the target, or here also the cache address), resulting in a two-clock delay for BTAC prediction.

[0027] BTAC 14 features a two-clock taken penalty, which also reveals the benefit of fast branch prediction (without taken penalty) provided by the fast predictor 12 by immediately guiding the new cache address as the target. In one embodiment, BTAC 14 is larger than the fast predictor 12 and has a more sophisticated branch prediction mechanism, configured (e.g., always) to rewrite the branch prediction of the fast predictor 12 when inconsistencies exist in the branch predictions (e.g., the branch prediction determined by BTAC 14 differs from the take decision and / or branch target address determined by the fast predictor 12). In some embodiments, BTAC 14 is configured to update the fast predictor 12 during one of the BTAC levels (e.g., level U) by writing branch prediction information to a table in the fast predictor 12 (and also to a table in BTAC 14). In some embodiments, updates to BTAC 14 are delayed until the branch is executed or retired, wherein updates to BTAC 14 involve writing to the predictor table of BTAC 14. In one embodiment, the update involves target information updates and / or counter updates. However, updates to the fast predictor 12 do not wait that long, but occur during the BTAC stage. Note that branches not in the fast predictor 12 are written into the fast predictor 12 two cycles later at the time corresponding to the BTAC stage (e.g., during the BTAC stage).

[0028] XIB 16 is an entry queue where each entry holds 16 bytes of data from the instruction cache. For example, the cached data from XIB 16 is only a stream of instruction bytes in 16-byte blocks, and given that instructions have variable lengths, it is unknown where a given x86 instruction begins or ends within the stream or within a given block. XIB 16 includes known logic for determining and marking the start and end bytes of each instruction within the stream, thereby breaking the byte stream into a stream of x86 instructions, which is provided to and stored in the FIQ / circular queue 20 for processing by the rest of the microprocessor pipeline. At the L (length) level, XIB 16 determines the instruction length. In one embodiment, the pre-decoder ( Figure 1A (Not shown) is implemented at level U and configured to detect potential branch instructions and mark them in a queue for each instruction byte. Note that at this level, there is ambiguity regarding whether a given byte is the start of an instruction. If the byte is the opcode byte of a branch instruction determined later (level M), the instruction is identified as a branch instruction. For example, branch decoder 18 includes instruction multiplexing (not shown) for multiplexing instructions in multiplexing or level M, where branch instructions are identified in this way.

[0029] In stage F, these instructions are formatted as described above. In one embodiment, the formatting instructions include instructions that substantially conform to the x86 architecture instruction set. Furthermore, in stage M, it is determined whether a given instruction (possibly pre-marked by the pre-decoder) is indeed a branch. For example, in the event of a miss at fast predictor 12 or BTAC 14 (e.g., at initial startup), branch decoder 18 (e.g., instruction multiplexing) determines that the current instruction is a branch, writes to the BOT, and redirects the cache address to the new target and updates the table in the front end of microprocessor 10 in stage G. In effect, when a miss occurs at fast predictor 12 or BTAC 14, branch decoder 18 provides branch prediction, where the branch instruction is redirected to the target in stage C. In some cases, such as when there are more than a finite or predetermined maximum number of branches for each fetch at BTAC 14 (e.g., more than three branches for each 16-byte fetch), branch prediction for additional branches is delayed until decoding time.

[0030] FIQ / Circular Queue 20 receives and buffers formatting instructions until they can be translated into microinstructions. FIQ / Circular Queue 20 also provides preliminary decoding and fast looping functionality (e.g., on a BTAC loop branch, the circular queue is activated and the loop instructions are repeatedly sent), the latter indicated by the arrow on the right side of box 20.

[0031] The W class offers an optional additional timing clock.

[0032] At level X, instruction translator 22 (in level X or translation level) translates the formatted instructions stored in FIQ / circular queue 20 into microinstructions.

[0033] Instructions are provided to Register Alias ​​Table / Reservation Table (RAT / RS) 24 in program order. The RAT function of RAT / RS 24 maintains and generates dependency information for each instruction. The RAT function of RAT / RS 24 renames the source and destination of instructions to internal registers and dispatches instructions to reservations in RAT / RS 24, which (possibly out of program order) issue instructions to function unit 26. Function or execution unit 26, including integer units, executes branch instructions at E (execution) level. Execution unit, branch unit, and integer unit are terms used interchangeably herein. In one embodiment, execution unit 26 (e.g., two execution units) executes two branches in a single clock cycle. Execution unit 26 also indicates whether BTAC 14 has correctly predicted the branch instruction.

[0034] In one embodiment, the result of execution is provided to a reordering cache (not shown), which includes information related to the instructions that have been executed. It is well known that reordering caches maintain the original program order of instructions after they are issued and allow serialization of results during exit stages. In one embodiment, some of the information in the reordering cache may be stored elsewhere in the pipeline, such as at decoder 18. The information stored in the reordering cache may include branch information, such as the type of branch, branch pattern, target, tables used in prediction, and cache replacement policy information (e.g., Least Recently Used or LRU).

[0035] Branch table update 28 includes S, W, Y, and Z levels and is configured to update various tables (e.g., BTAC, TAGE) at the front end with information related to the fully decoded and executed branch instructions (e.g., the final result of the branch) (e.g., at the S level). At the S, W, Y, and Z levels, updates may involve table reads, target address writes, and counter increments or decrements, which may involve some latency. In one embodiment, branch table update 28 provides an indication of error prediction for a given conditional branch instruction and the edge (e.g., A, B, or C) that caches that conditional branch instruction.

[0036] Now for reference Figure 1B And continue to refer to Figure 1A , showing in response to Figure 1A The microprocessor 10 shown illustrates an example fast predictor 12 and other exemplary sources used at the front end 30 of a branch unit pipeline. The front end 30 includes an fetch unit 32 (e.g., including multiplexing and clock registers), a translation back buffer (TLB) 34, an instruction cache (I cache data) 36, I cache tags 38 (or a tag array), a BTAC 14, and the fast predictor 12. The fetch unit 32 receives multiple cache instruction address sources, including sequential instruction addresses (e.g., from I level), corrected instruction addresses (e.g., from S level), decode-time instruction addresses (e.g., from G level), and addresses from the BTAC 14 and the fast predictor 12. The output of the fetch unit 32 is a cache address provided as input to the TLB 34, I cache data 36, ​​I cache tags 38, BTAC 14, and the fast predictor 12 for accessing the next instruction of the I cache data 36.

[0037] TLB 34, under the management of the memory management unit (not shown), provides virtual-to-physical page address translation as is known. That is, TLB 34 stores the physical address of the most recently used virtual address. TLB 34 receives the linear address from the segmentation unit (which translates logical addresses from the program into linear addresses) and compares a portion of that linear address with entries in TLB 34 to find a match. If a match is found, the physical address is calculated based on the TLB entry. If no match is found, a page table entry is retrieved from memory and placed into TLB 34.

[0038] I cache data 36 includes Level 1 caches containing instructions that have been fetched or pre-fetched from L2, L3, or main memory. I cache data 36 includes multiple clock registers.

[0039] I cache tag 38 includes an array of tags corresponding to instructions in I cache data 36, ​​and includes multiple clock registers for determining the match between information associated with the picked-up cache instruction (e.g., a tag or portion of a cache address) and I cache data 36 and BTAC 14.

[0040] The above text combined Figure 1A BTAC 14 is described, and it has multiple clock registers and a two (2) clock take penalty. Similarly, the fast predictor 12 described above has a zero (0) clock take penalty. For example, assume fetching along the I cache at 16 bytes per cycle, and assume a branch instruction from cache address 20 to cache address 95. Note that the address descriptions in this example imply hexadecimal representation (e.g., 0x0, 0x10, 0x20, etc.). Thus, the fetch occurs at cache address 0, cache address 10, cache address 20 (the branch instruction, but not yet resolved due to the multiple cycles of reads and multiplexing in BTAC 14, which in some embodiments are the same timing as the I cache), cache address 30 (relative clock 1), cache address 40 (relative clock 2), and then on the third clock (relative clock 3), the cache instruction fetch is redirected to cache address 95. Therefore, the branch penalty in this example comprises two clock cycles because cache addresses 30 and 40 occur after the branch. In other words, without the fast predictor 12, the branch penalty for this particular design example would always be two clock cycles. Using the smaller and faster fast predictor 12, cache address fetches (in the above example) include 0, 10, 20, and 95, with no latency to the cache address and zero penalty. As mentioned above, in some embodiments, the fast predictor 12 can be omitted.

[0041] Before proceeding with a more detailed description of some embodiments of the branch prediction security system, the Spectre vulnerability is further explained below. Generally, a vulnerability or security flaw can be understood in the context of user-programmed code and supervisory programming code. Supervisory code refers to code that requires higher privileges or security authorization to access, including code related to cryptographic rules, privacy data, etc., which is typically intended only for privileged access within a website or operating system (e.g., by those with appropriate security credentials, such as administrators of a website or cloud computing service). Supervisory code can include kernel code involved in an operating system or hypervisor. User code, on the other hand, is code that can be run by a user and has lower privilege requirements than supervisory code. User code should not be able to access supervisory code. At the hardware level, the chip implements security protocols to prevent access from lower privilege levels to higher privilege levels (e.g., between users and / or applications). The Spectre security flaw can exploit speculative branch prediction mechanisms in the chip by inferring the nature of data from timing patterns to access the data, and more specifically, by exploiting indirect branch prediction mechanisms. Mitigation techniques such as IPB and even IBSS eliminate indirect branch instructions, such as in BTAC, when transitioning from lower (user code) to higher (supervisory) privileged code. For example, indirect branches are cleared when transitioning to or from supervisor code or patterns. In another technique known as retpoline, each indirect branch is replaced with a return target. However, as explained above, indirect branch clearing can degrade performance given a mix of prediction table sizes, path layouts, and branch types. Furthermore, retpoline is implemented at the compiler level, where, aside from embedded applications that may have limited software libraries, it involves more code modifications than hardware fixes given the extent and scope of the software application.

[0042] Given the above additional background, we will now turn our attention to... Figure 2 , Figure 2An example branch prediction security system 40, partially based on the Indirect Branch Restriction Speculation (IBRS) mitigation technique of the Spectre Variant II vulnerability, is shown. Typically, the branch prediction security system 40 prevents user code from influencing supervisory code. More specifically, there are two variations of the approach implemented by the branch prediction security system 40. One variation requires that privilege levels (or equivalently, predictor patterns) match precisely, while the other variation requires that lower-privileged code cannot influence higher-privileged code. In one embodiment, the branch prediction security system 40 includes a BTAC 14 (but in some embodiments, other branch prediction table types may be used), and a BTAC entry 42 includes a valid entry 44, a predictor pattern (PM) label 46 (or privilege level label), an address label 48, and a data entry 50. The valid entry 44 includes a 1-bit setting indicating whether a branch instruction in the BTAC 14 is valid. The predictor pattern label 46 includes a 2-bit value corresponding to any one of the four (4) privilege levels. The address label 48 and the data entry 50 correspond to address identifiers or indices for branch instructions and branch information or data, respectively.

[0043] The branch prediction security system 40 also includes logic 52 for receiving information from the selection entry of BTAC entry 42 and enhancing security by invalidating branches that do not meet certain privilege level conditions. In some embodiments, logic 52 is part of or works in cooperation with BTAC 14. Logic 52 includes comparator logics 54 and 56 and a multiplexing selection 58. In one embodiment, comparator logic 54 receives the current predictor mode and PM tag 46 of a fetched branch instruction (e.g., an indirect branch instruction) and performs a privilege level check. The privilege level check determines whether the current predictor mode is equal to the PM tag 46 and whether the predictor mode is greater than or equal to the PM tag 46 (e.g., a lower privilege code cannot affect a higher privilege code), and when satisfied, triggers multiplexing selection 58 to provide a PM match output. This operation is performed in conjunction with tag matching. That is, comparator logic 56 receives the fetch address and address tag 48 and provides a tag match when these values ​​are equal. In practice, the conditions leading to a hit in BTAC 14 include a valid tag 44, a tag match from comparator logic 56, and a PM match from multiplexing selection 58. Conversely, access is denied between codes at different privilege levels by causing a miss (and therefore not being predicted) when the privilege test fails. It is worth noting that, unlike conventional fixes that use microcode to clear the predictor for each change in code privilege level, some embodiments of the branch prediction safety system 40 preserve branches, and the preserved branches are only accessible at the same privilege level. In the context of this invention, those skilled in the art will understand that... Figure 2The arrangement of components depicted is an exemplary embodiment, and in some embodiments, other arrangements of components may be used to achieve similar functionality, and therefore other arrangements are contemplated within the scope of the invention.

[0044] Now for reference Figure 3 This illustrates an embodiment of an example branch prediction security system 60 that is partially based on the Indirect Branch Predictor Barrier (IBPB) mitigation technique for the Spectre Variant II vulnerability. As indicated above, the IPB is implemented by the branch prediction security system 60 by clearing indirect branches in the branch prediction table (e.g., BTAC 14) when transitioning from a lower privileged code to a higher privileged code. In one embodiment, as described below, the branch prediction security system 60 performs this function using a separate indirect validity table. The branch prediction security system 60 includes a plurality of paths (table entries) 62, and in this example, four (4) BTAC paths 0, 1, 2, and 3 (e.g., for each of the edges A, B, C, etc.). It should be understood that in some embodiments, fewer or additional BTAC paths 62 may be used, and this is therefore contemplated within the scope of the invention. The branch prediction security system 60 also includes comparator logic 64, a path multiplexer 66, and an indirect validity table 68. The indirect validity table 68 stores the valid bit entries (e.g., indirect validity bit entries) for indirect branch instructions for BTAC 14. The indirect valid table 68 is much smaller than BTAC 14, where in one embodiment, each entry is a single bit in length. The indirect valid table 68 can be cleared in a single clock cycle. As those skilled in the art will understand in the context of this invention, clearing the indirect valid table 68 can be done simply using a normal signal. The low power / current constraints of this small table (e.g., containing only indirect valid bits) and the availability of sufficient current to simultaneously clear all bits of the table make a single clock cycle clearing of all entries possible.

[0045] Further, in one embodiment, the indirect valid table 68 includes multiple rows and one or more entries for each row. For example, the indirect valid table 68 includes a physical arrangement of sixty-four (64) rows × sixteen (16) bits, wherein each bit entry (e.g., a column) includes registers and drivers (to provide the necessary current) to latch and allocate a clear bus (e.g., 16 bits) to all random access memory (e.g., SRAM) cells in table 68. Entries can be cleared individually, or the entire table can be cleared at once (e.g., in a single clock cycle) using, for example, a transistor for each cell, which zeroes the memory state of the cell when activated by a clear signal. When the clear signal is not activated, the cell functions as a normal SRAM cell. The 64-row × 16-bit table is also multiplexed to logically produce an indirect valid table configuration. In one embodiment, the indirect valid table 68 includes a 512 × 2-bit table, where one bit entry is associated with a main valid entry, while other entries are associated with indirect valid entries. In some embodiments, the multiplexer can produce a 512×1 bit table, where each entry is associated only with indirect validity (and entries in BTAC 14 are primary validity).

[0046] BTAC path 62 provides corresponding outputs to multiplexer 66 and comparator logic 64. In one embodiment, comparator logic 64 receives an indication of branch type (e.g., indirect branch, 4 bits) from BTAC path 62, and in another embodiment, it also receives a primary valid entry and address tag match from BTAC 14 (e.g., from entries of BTAC 14 for picked-up branch instructions). Another input to comparator logic 64 is an indirect valid entry from indirect valid table 68. Comparator logic 64 provides a hit indication to multiplexer 66, where a hit corresponds to a primary valid, indirect valid (e.g., as provided via indirect valid table 68) indirect type, and address tag match. On the other hand, when indirect valid table 68 is cleared, BTAC entries are still considered invalid based on the cleared indirect valid table entries, regardless of the valid entries of BTAC 14 (e.g., valid or invalid). In other words, when reading BTAC 14, it can be determined (e.g., by comparator logic 64) that a primary valid indirect branch type exists for a given address label, but if the input from the indirect valid table 68 indicates an indirect invalid bit, the indirect branch instruction is invalidated, thus preventing its use after transitioning from user code to privileged or supervisory code (and thus preventing malicious code from using indirect branch instructions to exploit Spectre-type security vulnerabilities). In fact, in parallel with BTAC 14, the indirect valid table 68 enables the reading of second valid bit entries (outside of the primary valid entry or the BTAC valid entry, or the primary valid entry in the indirect valid table as described above), and the indirect valid table 68 is designed to be clearable in a single cycle, thus avoiding the performance impact expected from clearing indirect branches from the much larger BTAC 14. The hits generated based on primary validity, indirect type branch instructions, indirect validity, and address label matching are provided to the path multiplexer 66, and a BTAC output is produced (e.g., information on branch instructions with a specific address, path, side, target, and type of branch instruction). In the context of this invention, those skilled in the art will understand that Figure 3 The arrangement of components depicted herein is an exemplary embodiment, and in some embodiments, other arrangements of components may be used to achieve similar functionality, and therefore other arrangements are contemplated within the scope of the invention.

[0047] In the context of this invention, those skilled in the art will understand that some embodiments of the microprocessor can be configured to perform both methods (IBRS-based embodiments and IPB-based embodiments), and some embodiments may be able to perform only one or the other method.

[0048] Some embodiments of the branch prediction safety system 40 have been described. It should be understood that one embodiment of the example branch prediction safety method implemented in a microprocessor and based on IBRS (denoted as...) Figure 4 Method 70) includes: receiving a picked branch instruction (72); performing a privilege level test on the picked branch instruction using a privilege level indicated by a first label corresponding to a privilege level in a branch prediction table comprising multiple entries, each of the multiple entries including a label corresponding to a privilege level (74); and providing a predicted branch miss for the picked branch instruction based on the failure of the privilege level test (76).

[0049] Having described some embodiments of the branch prediction safety system 60, it should be understood that yet another embodiment, implemented in a microprocessor and based on the example method of IPB (denoted as...), is... Figure 5 Method 78) includes: receiving an indirect branch instruction fetch at a branch prediction table containing a plurality of entries, wherein at least a portion of the plurality of entries corresponds to an indirect branch type (80); and the entry in the branch prediction table corresponding to the indirect branch instruction being configured to invalidate based on the clearing of the corresponding entry in the indirect validity table (82).

[0050] Any processing description or box in the flowchart should be understood as representing a module, segment, logic, or part of code (which includes one or more executable instructions for implementing a particular logical function or step in the process), and alternative implementations are included within the scope of the embodiments, wherein, as those skilled in the art will understand, functions may be performed in a different order than shown or discussed (including substantially concurrent execution or execution in a different order), depending on the functions involved.

[0051] While the invention has been shown and described in detail in the accompanying drawings and the foregoing description, such showing and description should be considered illustrative or exemplary rather than restrictive; the invention is not limited to the disclosed embodiments. Other variations of the disclosed embodiments can be understood and implemented by those skilled in the art in practicing the claimed invention by studying the drawings, the disclosure, and the appended claims.

[0052] Note that different combinations of the disclosed embodiments may be used, therefore referring to an embodiment or one embodiment does not imply that features from that embodiment are excluded from being used with features from other embodiments. In the claims, the word "comprising" does not exclude other elements or steps.

Claims

1. A microprocessor, comprising: A branch prediction table comprising multiple entries, wherein a first portion of the multiple entries corresponds only to indirect branch types, and a second portion of the multiple entries corresponds to one or more other branch types; Indirect effective table; Logic for configuring only multiple entries in the first part of the branch prediction table corresponding to indirect branch instructions as invalid by clearing corresponding multiple entries in the indirect validity table; and Logic for clearing the plurality of entries in the indirect valid table in a single clock cycle.

2. The microprocessor according to claim 1, wherein, Each entry in the plurality of entries corresponding to the indirect branch instruction in the first part includes a valid bit entry, wherein the valid bit entry in the branch prediction table is valid or invalid.

3. The microprocessor according to claim 1, wherein, Invalid configuration of multiple entries in the first part of the branch prediction table prevents branch prediction corresponding to multiple entries in the first part after a transition from a lower privilege code level to a higher privilege code level.

4. The microprocessor according to claim 1, wherein, The predicted target of at least one of the indirect branch instructions was tampered with by malicious code as part of a Spectre vulnerability attack.

5. The microprocessor according to claim 1, wherein, The branch prediction table and the indirect effective table are read in parallel.

6. The microprocessor according to claim 1, wherein, Branch prediction table hits for indirect branch instructions are based on: address label matching of the branch prediction table, the major valid bit of the branch prediction table or the indirect valid table, and the indirect valid bit in the indirect valid table.

7. The microprocessor according to claim 6 further includes a branch prediction table multiplexer, wherein, The indication of a hit in the branch prediction table is used to select the output of the branch prediction table.

8. The microprocessor according to claim 7, wherein, The output includes the branch target and the branch type.

9. The microprocessor according to claim 1, wherein, The branch prediction table includes a branch target address cache, namely BTAC.

10. A method implemented in a microprocessor, the method comprising: The target of an indirect branch instruction is predicted using a branch prediction table comprising multiple entries, wherein a first portion of the multiple entries corresponds only to an indirect branch type, and a second portion of the multiple entries corresponds to one or more other branch types; Only the multiple entries in the first part of the branch prediction table corresponding to the indirect branch instruction are configured to be invalidated based on the clearing of the corresponding multiple entries in the indirect validity table; and The plurality of entries in the indirect valid table are cleared in a single clock cycle.

11. The method according to claim 10, wherein, Each entry in the plurality of entries corresponding to the indirect branch instruction in the first part includes a valid bit entry, wherein the valid bit entry in the branch prediction table is valid or invalid.

12. The method according to claim 10, wherein, Invalid configuration of multiple entries in the first part of the branch prediction table prevents branch predictions corresponding to multiple entries in the first part of the branch prediction table after a transition from a lower privilege code level to a higher privilege code level.

13. The method according to claim 10, wherein, The predicted target of at least one of the indirect branch instructions was tampered with by malicious code as part of a Spectre vulnerability attack.

14. The method of claim 10 further comprises reading the branch prediction table and the indirect validity table in parallel.

15. The method according to claim 10, wherein, Branch prediction table hits for indirect branch instructions are based on: address label matching of the branch prediction table, the major valid bit of the branch prediction table or the indirect valid table, and the indirect valid bit in the indirect valid table.

16. The method of claim 15, further comprising outputting from the branch prediction table based on providing an indication of a hit in the branch prediction table to a multiplexer to which the branch prediction table is fed.

17. The method according to claim 16, wherein, The output includes the branch target and the branch type.

18. The method according to claim 10, wherein, The branch prediction table includes a branch target address cache, namely BTAC.

Images