Abstract:
In general, in one aspect, a computer-implemented method includes determining a digest value based on hash operations on values of, at least, a set op-codes of multiple instructions of a program during execution of the program by a processor.

Description:
BACKGROUND 
     Increasingly, computer applications interact cooperatively across different network nodes. For example, on-line gaming typically features player client programs interacting with a gaming server that reconciles and responds to the actions taken by the different players. This distributed architecture, however, has proven highly susceptible to cheating. For example, some software developers provide unscrupulous users with computer programs that modify or replace the authorized client software. These programs can provide unfair advantages, for example, by replacing human interaction with computer generated responses (e.g., automated targeting). In multi-player games, this offers a very un-level playing field for gamers. On-line gaming is just one example of the difficulty in providing trusted computing in a distributed or otherwise unprotected environment. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates generation of a digest value for a set of instructions. 
         FIG. 2  is a flow-chart of a process to compare a digest value of a set of instructions with an expected value. 
         FIG. 3  is a diagram of a processor. 
         FIGS. 4 and 5  are flow-charts of context switching in a processor that generates a digest value for a set of instructions. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  illustrates a technique that generates a digest value  108   a - 108   c  representing instructions  102   a - 102   c  of a program executed by a processor. As shown, during execution of a program  102 , a digest value  108   a - 108   c  is updated for each instruction  102   a - 102   c . This digest value  108  can, with very high likelihood, be used to determine that a set of instructions  102   a - 102   c  were actually executed by a processor. For example, comparing the digest value  108  with an expected digest value can be used to determine whether an authorized program is interacting with a server instead of an unauthorized or modified program. 
     In greater detail,  FIG. 1  lists instructions  102   a - 102   c  of a program in assembly code mnemonics for ease of illustration. As shown, a given instruction  102   a - 102   c  features a binary op-code identifying what operation a processor is to perform during instruction execution. For example, a “MOV” instruction  102   a  may have a binary op-code of “00000101” (05xh). Many instructions operate on operands. For example, instruction  102   a  uses registers r 1  and r 2  as operands. In addition to op-codes and operands, a given instruction may feature other fields such as the operand-size, address-size, option instruction prefix, and so forth. 
     As shown, the op-code  106   a - 106   c  of each instruction contributes to the generation of a digest value  108   a - 108   c . In the example shown, the op-code  104   a - 104   c  undergoes a hash operation that transforms the op-code  104   a - 104   c  into a hash value  106   a - 106   c . For example, the hash operation may be a cryptographically strong algorithm such as a SHA (Secure Hash Algorithm) (e.g., SHA-256) or a non-cryptographic algorithm such as a CRC (Cyclic Redundancy Check) (e.g., CRC32). The digest value  108   a - 108   c  represents an accumulation of the hash values  106   a - 106   c  to reflect execution of each instruction  102   a - 102   c . For example, the digest value  108   a - 108   c  may represent a simple running accumulation of hash values  106   a - 106   c . Alternately, other aggregation techniques may be used (e.g., XOR-ing a hash value with the current digest value). The digest value  108   a - 108   c  may also be a function of the previous digest value  108   a - 108   c  and an additional op-code (e.g., digest=hash (digest value, op-code)). Such approaches can produce different digest values for the same set of instructions executed in a different order. 
     The hash value may be of a different data width than the op-code width. For example, a hash value may feature fewer bits than an op-code to compactly represent an instruction. Alternately, a hash value may feature more bits than an op-code to map the op-codes into a larger space and reduce the likelihood that a sequence of op-codes would generate the same accumulated hash values. 
     As shown, the hash operation operates solely on the op-codes of an instruction. In some systems, the op-code also encodes operands on an instruction though in others this information is stored in a separate instruction field. In some implementations, in addition to the instruction op-code, the hash operation may also include the encoding of operands, flags, or processor state information. In most implementations, the hash operation does not operate on the values stored in the operands or the instruction address of an op-code to make the hash output memory location independent and independent of data values. However, in other implementations such data may be used, though such information may reflect the operational state of a program which may vary significantly across different executions and make comparison with an expected value more difficult. 
     As shown in  FIG. 2 , since the digest value  122  is a direct measurement of execution history, comparing  124  this hash value with an expected value can provide a measure of confidence that a body of code executed without modification. Such techniques can be used in a wide variety of applications. For example, the technique above may be used in trusted computing applications, such as online gaming or Internet voting. For example, a digest value  108  can be included in a network packet (e.g., in an IP (Internet Protocol) datagram and/or a Transmission Control Protocol (TCP) segment) and transmitted to a server for comparison with an expected value or set of expected values. The digest value  108  may be transformed prior to or after inclusion in the packet, for example, by a key to permit authentication of the value. A remote node (e.g., a node having a different Internet Protocol address) can then compare the digest value or transformed digest value with an expected value. The techniques may also be used in other applications. For example, in an automated regression testing environment, the digest value can attest that a program executed an expected set of instructions in an expected order in response to a set of test data. 
     The techniques describe above may be implemented in a variety of ways. For example,  FIG. 3  illustrates a pipelined processor  200  architecture that includes logic blocks  216 ,  218  to determine digest values based on instructions executed by the processor  200 . By integrating the logic into the processor  200 , the digest value can be determined without dependence on, and regardless of the integrity of the surrounding software. That is, the security scheme is less vulnerable to tampering by an operating system, drivers, a VMM (Virtual Machine Monitor) layer, processor simulator, etc. 
     The processor  200  shown features a fetch block  202  that retrieves a macro instruction op-code (macro-op) from an instruction store (e.g., an instruction cache) and sends the op-code to the decode logic in program order. The decode block  204  decomposes the macro-op into one or more micro-ops and forwards the macro-op and micro-ops to reservation logic  206 . The reservation block  206  allocates entries for the micro-ops in a re-order buffer block  208  that maintains the state of the micro-ops. Each micro-op entry in the buffer  208  has an associated reservation ID. The reservation block  206  also notifies a macro-op buffer block  214  of the macro op-code and the reservation ID of the last micro-op to be executed for the macro op. The execute block  210  executes the micro-ops and updates the re-order buffer  208  to reflect micro-op execution. When micro-ops are marked in the re-order buffer  208  as executed by the execute block  210 , a retire block  212  removes the micro-ops from the re-order buffer  208  and provides the reservation ID to the macro-op buffer block  214 . When the macro-op buffer block  214  detects the reservation ID of the last micro-op to be executed for a given macro op, the macro-op buffer block  214  can both retire the macro-op from the macro-op buffer block  214  and present the macro op to the hash generator block  216 . Regardless of when a macro-op is retired, the hash generator block may process the macro-op in instruction execution order. This may require buffering of a macro-op in the hash generator block or selecting among multiple macro-ops retired on the same cycle, for example, by reservation ID. 
     The hash generator block  216  transforms the bits of the macro-op code into a hash value. The hash generator block  216  may be composed of several stages, e.g., a pipeline, to increase hashing throughput at the expense of latency in computing the hash value. If the hashing logic design is such that it may fall behind the retirement rate, the hash generator block  216  can supply back pressure to stall the pipeline or may feature a buffer to queue retired macro-ops. The hash register block  218  stores an accumulated hash value. 
     The processor  200  shown may feature instructions for use with the digest generation scheme. For example, the hash value mechanism may be enabled or disabled by processor instructions (e.g., DIGEST-ON or DIGEST-OFF instructions). When disabled, the macro-op buffer block  214  ignores all macro-op codes until the block  214  detects the retirement of the macro-op code associated with the instruction to enter digest execution mode The ability to control digest generation can permit programmers or a compiler to isolate sections of code where there is little or no conditional branching. This can ease the task of generating a set of possible expected values. This ability can also permit software systems that are not concerned with security or instruction execution verification to avoid or reduce potential execution or power consumption penalties contributed by digest generation. Macro-op codes of these DIGEST-ON/DIGEST-OFF instructions may either be included or excluded from representation in the digest value. 
     In addition to an instruction or instructions that enable/disable digest value generation, the processor  200  may feature an instruction that resets the hash register value  218  when executed. The processor  200  may feature an instruction that provides a value to hash generator  216  for representation in the digest value. Such an instruction can permit a program to provide a potentially variable seed starting value to the digest generation. Finally, the processor  200  may feature an instruction that retrieves the digest value  218  or permits use of the hash register  218  as an instruction operand. 
     Potentially, the processor  200  may feature a secret block  220  to operate on a digest value with a processor secret value. For example, when the digest value is retrieved, the value of the secret block enables a processor to provide attestation to the fact that the digest value was computed by the processor hardware. The attestation may take the form of a cryptographically secure signature of the digest value by the processor secret value. 
     The processor  200  architecture shown is merely an example, and the techniques can be implemented in a wide variety of other architecture. However, the architecture shown illustrates features that can advantageously be incorporated within other different designs. For example, by having the digest logic operating in parallel with instruction execution, the architecture shown can potentially generate a digest value without a substantial speed performance impact in instruction execution. 
     Potentially, the processor  200  may switch between different threads of execution. To preserve a thread-specific digest value, digest data may be included in the thread context saved during a context switch. For example, as shown in  FIG. 4 , in addition to conventional thread context data  304 ,  310  (e.g., program counter, flag values, and so forth) data indicating whether digest generation is enabled  312 ,  314  may also be saved. If digest generation is enabled  302 , the current digest value may be saved  314 . In addition, an integrity check may also be saved, for example, by cryptographically signing the current digest value with a processor secret key (e.g., by the secret block  220 ). 
     As shown in  FIG. 5 , when a context is restored  402 , if the thread currently has digest generation enabled  406 , the current digest value can be restored  408  and the integrity check may be retrieved and compared with a recomputation of an integrity check value, e.g., by the secret block  220 , to ensure the digest value has not been tampered with. 
     Techniques describe herein may be implemented in hardwired circuitry, digital circuitry, analog circuitry, programmable circuitry, and so forth. The programmable circuitry may operate on computer programs. The computer programs may be stored on a computer readable medium and include instructions that cause a processor to operate in ways described above 
     Other embodiments are within the scope of the following claims.