Method and apparatus for establishing secure sessions

A method and apparatus for processing security operations are described. In one embodiment, a processor includes a number of execution units to process a number of requests for security operations. The number of execution units are to output the results of the number of requests to a number of output data structures associated with the number of requests within a remote memory based on pointers stored in the number of requests. The number of execution units can output the results in an order that is different from the order of the requests in a request queue. The processor also includes a request unit coupled to the number of execution units. The request unit is to retrieve a portion of the number of requests from the request queue within the remote memory and associated input data structures for the portion of the number of requests from the remote memory. Additionally, the request unit is to distribute the retrieved requests to the number of execution units based on availability for processing by the number of execution units.

FIELD OF THE INVENTION

The invention relates to the field of processing. More specifically, the invention relates to an interface for a security coprocessor.

BACKGROUND OF THE INVENTION

Communication networks and the number of users of such networks continue to increase. Moreover, on-line sales involving both business-to-business and business to consumer over the Internet continues to proliferate. Additionally, the number of people that are telecommuting continues to grow. Both on-line sales and telecommuting are examples of usage of communication networks that typically involve private and sensitive data that needs to be protected during its transmission across the different communication networks.

Accordingly, security protocols (e.g., Transport Layer Security (TLS), Secure Sockets Layer (SSL) 3.0, Internet Protocol Security (IPSec), etc.) have been developed to establish secure sessions between remote systems. These security protocols provide a method for remote systems to establish a secure session through message exchange and calculations, thereby allowing sensitive data being transmitted across the different communication networks to remain secure and untampered.

FIG. 1illustrates a two phase client/server exchange to establish a secure session. In a first phase105, the security negotiation phase, a network element101(the client) and a network element103(the server) exchange messages to negotiate security between the two network elements101and103. The negotiation of security includes determining the algorithms (e.g., hashing algorithms, encryption algorithms, compression algorithms, etc.) to be employed by the two network elements101and103. In a second phase107, a key exchange phase, the network elements101and103exchange key information. The second phase107comprises the network elements101and103exchanging messages based on a selected public key algorithm and authenticating received messages. While the specific primitive tasks of these two phases vary for different security protocols, the primitive tasks for establishing a secure session can include the receiving of messages, transmitting of messages, generating of keys, generating of secrets, hashing of data, encrypting of data, decrypting of data, and calculating of random numbers.

Performing the tasks to establish a secure session is processor intensive. If a general purpose processor, acting as the host processor for a network element, performs these tasks, then the network element's system performance will suffer because resources will be consumed for the tasks. The results of poor system performance can impact a network and users in various ways depending on the function of the network element (e.g., routing, switching, serving, managing networked storage, etc.).

Coprocessors have been developed to offload some of the tasks from the host processor. Some coprocessors have been developed to perform a specific primitive task for the host processor (e.g., hash data). The addition of a task specific coprocessor does not offload from the host processor a significant amount of the secure session establishment tasks. One alternative is to add multiple coprocessors to a network element, each performing a different task. Such an alternative is limited by physical constraints (e.g., number of slots to connect cards) and introduces the problem of multiple communications between the host processor and the multiple coprocessors.

Other coprocessors have been developed to perform more than one of the tasks required to establish a secure session. Assume a coprocessor can perform a cryptographic operation (i.e., an encrypt or decrypt), a key material generation operation, and a hash operation. For example, assume a server has received a request to establish an SSL 3.0 session. The server must call the coprocessor to decrypt a pre-master secret received from a client. To generate a master secret and key material, the host processor must make 20 calls to the coprocessor (one for each hash operation). In just the beginning of establishing a single secure session, the host processor has made 21 calls to the multiple task coprocessor. As illustrated by this example, a coprocessor that can perform multiple tasks does not solve the issue of resource consumption from multiple communications between the host processor and the coprocessor.

Despite the addition of these coprocessors, a large amount of resources are still consumed with establishing secure sessions. Establishment of a secure session may suffer from latency caused by multiple communications between the host processor and a multiple task coprocessor or multiple single task coprocessors. Multiple communications between the CPU and coprocessors consumes system resources (e.g., bus resources, memory resources, clock cycles, etc.). The impact to the system can include limitation of 1) the number of secure sessions which can be served and 2) the number of concurrent secure sessions that can be maintained by the system.

SUMMARY OF THE INVENTION

A method and apparatus for processing security operations are described. In one embodiment, a processor includes a number of execution units to process a number of requests for security operations. The number of execution units are to output the results of the number of requests to a number of output data structures associated with the number of requests within a remote memory based on pointers stored in the number of requests. The number of execution units can output the results in an order that is different from the order of the requests in a request queue. The processor also includes a request unit coupled to the number of execution units. The request unit is to retrieve a portion of the number of requests from the request queue within the remote memory and associated input data structures for the portion of the number of requests from the remote memory. Additionally, the request unit is to distribute the retrieved requests to the number of execution units based on availability for processing by the number of execution units.

In one embodiment, a method executes on a host processor. The method includes storing a number of requests for security operations within a request queue within a host memory, wherein the number of requests are in an order within the request queue. The method includes storing data related to the number of requests for security operations into a number of input data structures within the host memory. The method also includes allocating a number of output data structures within the host memory, wherein a coprocessor is to write results of the number of requests for the security operations into the number of output data structures. The coprocessor can write the results in an order that is different from the order of the requests within the request queue. Additionally, for each of the number of requests, a thread for execution on the host processor is allocated, wherein the thread periodically checks a value of a completion code stored in the output data structure for the associated request. The completion code indicates that the request is completed by the coprocessor.

In an embodiment, a method includes retrieving, by a request unit, a number of requests for security operations from a host memory, wherein the number of requests are in an order within the host memory. The method also includes distributing, by the request unit, the number of requests for the security operations to a number of execution units. The distribution is based on availability of the number of execution units. Additionally, the method includes processing the number of requests for the security operations by the number of execution units. The method includes outputting results of the number of requests for the security operations to locations within the host memory, wherein an order of outputting of the results can be different from the order of the requests within the host memory.

DETAILED DESCRIPTION

A method and apparatus for processing security operations are described. In the following description, numerous specific details are set forth to provide a thorough understanding of the invention. However, it is understood that the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the invention. Although described embodiments of the invention refer to the SSL 3.0 protocol, alternative embodiments can be applied to other security protocols, such as IPSec, TLS, etc.

In the specification, the term “security operation” can be a primitive security operation or a macro security operation. A primitive security operation can be a decrypt operation, an encrypt operation, a hash operation, or a group of arithmetic operations for generating a value (e.g., a secret, key material, etc.). A macro security operation is a group of primitive security operations.

Overview

One aspect of the invention is the communication of tasks and results between a host processor and a security coprocessor, where the coprocessor has multiple execution units. Another aspect of the invention is the type of tasks, specifically macro security operations, that can be transferred by a host processor to a security coprocessor, where the coprocessor has multiple execution units. These two aspects can be used together. For example, in one embodiment, a security coprocessor with multiple execution units receives requests and provides results through a continuous flow mechanism. The received requests are treated as independent of each other, are distributed to available ones of the multiple execution units in-order, can be macro security operations, can take different amounts of time to complete, and can be completed/returned out-of-order. While these two aspects can be used together, they are independent of each other. In other words, macro security operations can be used with different (e.g., prior art) techniques for communicating tasks and results between a host processor and a security coprocessor; and vice versa.

System Description

FIG. 2is a block diagram illustrating a system for processing of security operations, according to embodiments of the present invention.FIG. 2includes host processor202, host memory204, coprocessor212and request processing unit234. Host processor202, host memory204and coprocessor212are coupled to system bus210. Additionally, host processor202, host memory204and request processing unit234are coupled together. In an embodiment, request processing unit234can be a process or task that can reside within host memory204and/or host processor202and can be executed within host processor202. For example, request processing unit234may be a driver fro the coprocessor executed by the host processor, wherein the driver interfaces with Open SSL. However, embodiments of the present invention are not so limited, as request processing unit234can be different types of hardware (such as digital logic) executing the processing described therein.

Host memory204stores request queue206, input data208A–208I and output data209A–209I. Request queue206is illustrated and described in terms of a queue. However, embodiments of the present invention are not so limited, as request queue206can be any other type of data structure for storage of requests to be transmitted to coprocessor212, which is described in more detail below. In one embodiment, request queue206is a circular queue (ring buffer). In an embodiment, the write pointer for request queue206is maintained by request processing unit234and the read pointer for request queue206is maintained by request unit214of coprocessor212. Accordingly, request processing unit234increments its write pointer when storing requests into request queue206, while request unit214decrements its read pointer when extracting or retrieving requests from request queue206.

Additionally, although input data208A–208I and output data209A–209I are data structures that are described as tables, such data can be stored in other types of data structures, such as data objects in an object-oriented environment. In one embodiment, input data208A–208I are contiguously stored in host memory204. Accordingly, request unit214within coprocessor212can extract the input data across multiple requests using one direct memory access (DMA) read operation, which is described in more detail below.

Requests inserted into request queue206by request processing unit234can include instructions, such as an operation code, the data to be operated on as well as a pointer to other locations in host memory204storing data (which is related to the request) that could not be placed into the request inside request queue206, due to restraints on the size of the requests. In particular, requests within request queue206can point to one of input data208A–208I. In one embodiment, these requests are 32 bytes in size. The types of requests can comprise different security operations including the macro security operations described below in conjunction withFIGS. 3–8. Additionally, such security operations could include, but are not limited to, a request to (1) generate a random number, (2) generate a prime number, (3) perform modular exponentiation, (4) perform a hash operation, (5) generate keys for encryption/decryption, (6) perform a hash-message authentication code (H-MAC) operation, (7) perform a handshake hash operation and (8) perform a finish/verify operation.

FIG. 3illustrates an exemplary request format for processing by coprocessor212, according to embodiments of the present invention. In particular,FIG. 3illustrates request format300that includes operation code302, size304, parameters306, data length308, data pointer310and result pointer312. Operation code302includes the op-code to identify the different security operations to be performed by coprocessor212, such as an op-code for hashing, modular exponentiation, etc. Size304can define sizes for different data related to the operation depending on the type of operation. For example, size304for a modular exponentiation operation could include the size of the modulus or for a hash operation could include the size of the data to be hashed.

Similar to size304, parameters306can define different data related to the operation depending on the type of operation. For example, for the operation for the generation of keys for encryption/decryption, parameters306could define the length of the pre-master for the key. To further illustrate parameters306, for the operation for the H-MAC operation, parameters306could define the length of the secret. In one embodiment, parameters306remain undefined for certain operations.

Data length308defines the length of the data structure within the associated input data208A–208I that is pointed to by data pointer310(within the request) and copied into coprocessor212for the security operation defined within the request. The data structure stored in the associated input data208A–208I and pointed to by data pointer310can include different data depending on the type of security operation to be performed. In one embodiment, for given operations, this additional data structure is not needed, thereby making data pointer310unused. For example, for the operation to generate a random number, there is no input data stored within one of input data208A–208I. To help illustrate the type of data to be stored within such data structures, for a key generation operation, the data structure could include the client random number, the server random number, the label and the pre-master number.

Result pointer312defines the location (one of output data209A–209I) within host memory204where coprocessor212can write output results into a data structure. In one embodiment, this write operation is performed by a DMA write operation. Additionally, in an embodiment, a completion code is placed at the end of this data structure (which is further defined below). Returning to the key generation operation to help illustrate, the data structure stored in the associated output data209A–209I could include the master key, the key material and the completion code.

Returning toFIG. 2, coprocessor212includes Peripheral Component Interconnect (PCI) unit230, lightening data transport (LDT) unit232, key unit244, request unit214, doorbell register220, execution units216A–216I, execution units217A–217I, random number generator unit218and request buffer222, which are coupled together. Additionally, PCI unit230and LDT unit232are coupled to system bus210. PCI unit230and LDT unit232provide communication between the different components in coprocessor212and host memory204, host processor202and request processing unit234. While one embodiment is described in which PCI and LDT units are used to connect to a system bus, alternative embodiments could use different buses.

The number of execution units216and217and the number of random number generator units218are by way of example and not by way of limitation, as a lesser or greater number of such units can be included within coprocessor212. A more detailed diagram and operation of execution units217A-217I is described below in conjunction withFIG. 8. Random number generator unit218generates random numbers for the generation of keys. Key unit244can store keys locally within coprocessor212for execution units217A-217I that can be subsequently used for processing of different security operations without requiring the retrieval of such keys from memory that is external to coprocessor212. Request unit214extracts requests within request queue206based on values inserted into doorbell register220and distributes such requests to execution units217A–217I for processing, which is described in more detail below. Request buffer222can store the requests extracted by request unit214for processing by execution units216–217.

Macro Security Operations

FIG. 4is a diagram illustrating an exemplary establishment of a secure SSL 3.0 session according to one embodiment of the invention. InFIG. 4, a client401and a server403exchange handshake messages to establish a secure session. The server403sends a set of security operations407,409,423, and425to the coprocessor212. Each of the set of security operations sent from the host processor201to the coprocessor212can be either a primitive security operation or a macro security operation. In the embodiment illustrated inFIG. 4, the set of security operations409,423, and425are macro security operations. Each macro security operation is performed by one of the execution units216–217of the coprocessor212.

The client401initially transmits a client hello message405to the server403. The client403may optionally send additional messages. The host processor201of the server403calls a random number security operation407to be executed by the coprocessor212. The random number generator218generates and stores a random number(s) in response to the random number operation407. In one embodiment of the invention, the random number operation407is a primitive security operation resulting in generation of a single random number. In another embodiment of the invention, the random number security operation is a macro security operation resulting in generation of a vector of random numbers. In an alternative embodiment of the invention, the host processor201calls the random number operation407to be executed by a random number generator218located separately from the coprocessor212. In another embodiment of the invention, random numbers are generated in advance of establishing the session. After the random number(s) is generated, the server403sends the security negotiation operation409to the coprocessor212.

After executing the security negotiation operation409, the coprocessor212creates a partial hash of the accumulated handshake messages (the client hello405and any optional messages). The server403uses the random number(s) and the data resulting from execution of the security negotiation operation409by the coprocessor212to create a set of messages transmitted to the client401. The server403transmits a server hello message411, a certificate413, and a server hello done message415. In another embodiment of the invention, additional optional messages are transmitted to the client401.

In the key exchange phase of establishing the SSL 3.0 secure session, the client401transmits a client key exchange message417, a change cipher spec message419, and a client finished message421. After the server403receives this set of messages,417,419, and421the host processor201on the server403calls a key exchange operation423and a finished operation425to be executed by the coprocessor212. As a result of executing the key exchange security operation423, the coprocessor212creates 1) a decrypted pre-master secret, 2) a master secret and key material, and 3) a partial hash of the accumulated handshake messages (the hashed client hello405and the set of messages417,419, and421). As a result of executing the finished operation425, the coprocessor212generates 1) a decrypted client finished message, 2) a finished hash for the client finished message421, 3) a finished hash for a server finished message429, and 4) an encrypted server finished message with its message authentication code (MAC). Using the data from the key exchange operation423and the finished operation425, the server4031) verifies the messages received from the client401and 2) transmits a change cipher spec message427and a server finished message429to the client401.

FIG. 5is a table illustrating groups of primitive security operations for the macro security operations illustrated inFIG. 4according to one embodiment of the invention. The negotiation security operation407, the key exchange operation409, and the finished operation425are identified in a column labeled “Macro Security Operations.” The table shows the group of primitive security operations executed by one of the execution units216–217of the coprocessor212when performing each of these macro security operations. When performing the security negotiation operation407, one of the execution units216–217executes 2 hash operations. To perform the key exchange operation409, one of the execution units216–217executes the following: 1) a decrypt operation; 2) a group of modular arithmetic operations; and 3) 22 hash operations (78 hash operations if establishing a secure session according to TLS). To perform the security negotiation operation407, one of the execution units216–217will execute 23 primitive security operations for SSL 3.0, according to one embodiment of the invention. To perform the finished operation409, one of the execution units216–217executes the following: 1) a decrypt operation; 2) an encrypt operation; and 3) 12 hash operations. One of the execution units216–217performing the finished operation407executes 14 primitive security operations.

The association of primitive security operations to macro security operations can be implemented in a variety of ways. Various implementations of the described invention may group primitive security operations for a macro security operation differently depending on factors that can include the security protocol, data dependencies, etc.

FIG. 6is a diagram illustrating an exemplary establishment of a secure session according to one embodiment of the invention. InFIG. 6, a different implementation of macro security operations is illustrated for the secure session establishment illustrated inFIG. 4. InFIG. 6, a server full handshake operation601is called instead of the macro security operations407,409, and423. The server full handshake macro security operation601is called after the server403receives the set of messages417,419, and421from the client401. With a single call, the coprocessor212(not including a call for random numbers) provides all the necessary data to the host processor201for establishing the secure session.

FIG. 7is a table illustrating a group of primitive operations for the server full handshake operation701according to one embodiment of the invention. One of the execution units216–217performing the server full handshake operation601executes the following primitive security operations: 1) a decrypt operation; 2) 2 encrypt operations; 3) a set of modular arithmetic operations; and 4) 35 hash operations. Thus, the execution unit executes approximately 39 primitive security operations to complete the server full handshake operation601. In this example of the server full handshake operation601, the client finished message421is not decrypted. The client finished message421is not decrypted because an expected client finished message is created by the coprocessor212. Since the contents of the client finished message421are known by the server403before actually receiving the client finished message421, the expected client finished message can be created and used to authenticate the received client finished message421without decrypting the client finished message421.

A client full handshake operation could create an expected server finished message. With the client full handshake operation, a client with a coprocessor212can perform a single call to the coprocessor212for establishing the secure session before receiving the server finished message429from the server401.

Thus,FIGS. 4–7illustrate a couple examples of how primitive security operations can be grouped together to form macro security operations. It should be understood that any combination of such primitive security operations is within the scope of the invention. With macro security operations, a secure session can be established with a limited number of communications between the host processor201and the coprocessor212of the client401or the server403. Fewer communication reduces consumption of system resources. Reduction in system resource consumption avoids decreased system performance. In addition, secure sessions can be established faster and a greater number of secure sessions can be maintained. Specifically, since the amount of processing required to process a macro security operation is greater than a primitive security operation, the allocation of operations to the different execution units in the security coprocessor allows for a greater throughput in spite of the overhead associated with such allocation.

FIG. 8is a diagram illustrating one of the execution units216–217according to one embodiment of the invention. InFIG. 8, a microcode block801is coupled to a microcontroller block803. The microcontroller block803is coupled to an execution queue block805. The execution queue block805is coupled to a set of primitive security operation blocks. The primitive security operation blocks include an Advanced Encryption Standard (AES) block807, a Triple Data Encryption Standard (3DES) block809, a modular exponentiation block811, a hash block813, a simple arithmetic and logic block815, and an alleged RC4® block819. Alternative embodiments of the invention may include additional primitive security operation blocks or fewer primitive security operation blocks. A bus821couples the primitive security operation blocks807,809,811,813,819and the register file block817together.

The microcode block801translates a security operation into one or more primitive security operations and passes the primitive security operation(s) to the microcontroller block803. The microcontroller block803retrieves from the register file817the appropriate data for each of the primitive security operations. The primitive security operations are placed into the execution queue805by the microcontroller block803. When a primitive security operation's corresponding primitive security operation block is able to perform the primitive security operation, the execution queue805pushes the primitive security operation to the appropriate primitive security operation block807,809,811,813,815, or819. Once a primitive security operation block807,809,811,813,815, or819has executed the primitive security operation, the primitive security operation block either passes the results to the register file817or onto the bus821. The result of the security operation of the request from the host processor201(be it a macro or a primitive security operation), is then caused to be transferred by the execution unit216–217via a DMA transfer to the appropriate location in the main memory.

While one embodiment is described in which each execution unit has its own microcode block, alternative embodiments have one or more execution units share a single microcode block. Yet other embodiments have a central microcode block (e.g., in SRAM) whose contents are loaded upcoming power-up into local microcode blocks in each of the execution units. Regardless of the arrangement of the microcode block(s), in certain embodiments the microcode blocks are reprogrammable to allow for flexibility in the selection of the security operations (be they macro and/or primitive security operations) to be performed.

A network element acting as a router, switch, access to a storage farm, etc., may establish one or more secure sessions. Macro security operations enable the network element to establish multiple secure sessions without consuming large amounts of system resources. Moreover, the secure sessions can be established faster with macro security operations.

For example, the coprocessor212may receive 3 requests to establish secure SSL 3.0 sessions. If the server full handshake operation701is implemented, then the host processor201can establish the secure sessions with 3 calls to the coprocessor212. The execution units216–217can perform the 3 operations in parallel. A more granular set of macro security operations may be implemented on the server similar to the macro security operations described inFIG. 4andFIG. 5. For example, the macro security operations described inFIG. 4andFIG. 5may be implemented on the server403that has received 2 requests for secure sessions. After the host processor201calls the coprocessor212to perform the client key exchange operation423for each of the two requested sessions, the server403receives a third request for a secure session. The host processor201calls the coprocessor212to perform the security negotiation operation409for this third secure session request. Although the request unit214of the coprocessor212issues the security negotiation operation409to one of the execution units216–217after issuing two client key exchange operations423to two of the execution units216–217, the one of the execution units216–217that performs the security negotiation operation409will complete execution of the operation409before the other two of the execution units216–217complete execution of their operations (assuming the security negotiation operation409requires less time than the key exchange operation423). Hence, operations from the host processor201may be issued to the execution units216–217in order, but completed by the execution units216–217out of order.

Utilizing the coprocessor212to perform functions for establishing secure sessions increases the efficiency of a system and its host processor201. The coprocessor212enables establishment of secure sessions with less consumption of host processor201resources. More secure sessions can be established at a faster rate. In addition, the overall performance of a system will improve since the host processor201can use resources previously expended for security functions. These host processor201resources can be applied to system monitoring, traffic monitoring, etc.

Furthermore, the parallel and out-of-order characteristics of the execution units216–217provide flexibility for implementing security operations. Various levels of granularity of macro security operations can be implemented to meet varying needs of a customer. While embodiments have been described that allow for out-of-order completion, alternative embodiments include hardware to require the in-order completion of requests.

In one embodiment, the request processing unit234is a coprocessor driver executed by the host processor. In one embodiment of the invention, the coprocessor driver interfaces with a modified version of Open SSL. The modified version of Open SSL is changed such that it communicates macro security operations to the driver as opposed to primitive security operations.

Processing of Security Operations by Request Processing Unit234

While system performance can be improved by reducing the number of communications between the host processor and the security coprocessor for a given secure session through the use of macro security operations, a manner of communicating tasks and results between the host processor and the security coprocessor that is more conducive to the coprocessor architecture can improve performance. Specifically, as previously indicated, another aspect of the invention is the communication of tasks and results between a host processor and a security coprocessor, where the coprocessor has multiple execution units. More specifically, a continuous flow capable task delivery and result return mechanism is used. A continuous flow capable task delivery and result return mechanism allows the host processor to continually add tasks (as long as the queue is not full) and the security coprocessor to continually return results (as opposed to a mechanism that requires a block of work to be completed by the coprocessor before another block of work can be transferred to the security coprocessor by the host processor). WhileFIGS. 2,9and10illustrate one implementation of a non-interrupt driven, continuous flow mechanism, alternative embodiments may use different continuous flow mechanisms.

To further illustrate the processing of the security operations,FIG. 9illustrates a flow diagram for the processing of requests by request processing unit234(shown inFIG. 2), according to embodiments of the present invention. Method900commences with the receipt of one to a number of requests for security operations, at process block902. In an embodiment, the request includes the macro operations and/or primitive operations described above. In one embodiment, request processing unit234stores data associated with the request, such as operands for the security operations, into one of input data208A–208I, at process block904. In particular, this data may be required to be stored external to request queue206due to the size constraints placed on an entry into request queue206. In an embodiment, this additional data storage is not required, as all of the associated data can be stored within a request within request queue206.

Additionally, request processing unit234allocates memory space for output data209A–209I for those requests to be stored in request queue206, at process block906. In one embodiment, request processing unit234sets the value of the completion code within the associated output data209A–209I to a value that does not indicate that the request is complete. For example, in one such embodiment, a value of zero indicates that the request is complete, and therefore, request processing unit234sets this value to a non-zero number.

Further, request processing unit234locks request queue206, at process block908. Accordingly, this locking precludes other units or processes from writing requests into request queue206. Although different techniques can be employed for locking request queue206, in one embodiment, request processing unit234locks request queue206through a software lock using a semaphore. Request processing unit234adds the request(s) into request queue206, at process block910. As described above in conjunction withFIG. 3, request can include the operation code to be performed by units within coprocessor212, a pointer to other data related to the operation that is stored in one of input data208A–208I and a pointer to the location in host memory204, such as output data209A–209I, where the output results are to be placed by coprocessor212after completion of the given request. Request processing unit234unlocks request queue206after adding the request(s), at process block912.

Request processing unit234writes the number of request(s) that were added into request queue206to doorbell register220(located on coprocessor212), at process block914. In one embodiment, this write operation is performed through a direct memory access (DMA) write operation. Although described as a register, the data to be stored in doorbell register220could include any other type of memory within coprocessor212.

Request processing unit234also generates threads for execution on host processor202, at process block916. In one embodiment, a thread is created for a given security session, such as a SSL 3.0 session. In one embodiment, request processing unit234creates a different thread for each request that is inserted into request queue206. These threads check for the completion of their associated requests by monitoring the completion code stored in the related output data209A–209I, at process block918.

In one embodiment, request processing unit234puts the thread to sleep when the associated request is placed into request queue206and sets a timer to wake the thread. Accordingly, when the thread commences processing, it checks the completion code within the related output data209A–209I to determine if the request is complete. In one embodiment, request processing unit234sets the value of this timer based on the particular request to be performed. For example, if a first request for generating a random number is typically processed by coprocessor212in a short duration in comparison to a second request for a key generation operation, request processing unit234sets the values of their timers accordingly. In other words, the first request would have a timer of shorter duration in comparison to the timer of the second request. In one embodiment, request processing unit234keeps the thread awake for a predetermined time and places the thread to sleep upon determining that the request is not been completed in during this time frame. In one embodiment, request processing unit234blocks on the event of the completion code being set by coprocessor212for the given request. While embodiments have been described in which request processing unit134uses threads to check completion codes, alternative embodiments could employ other mechanisms (e.g., request processing unit134could check each of the completion codes).

In one embodiment, upon completion of the request by coprocessor112, the associated thread can delete the requests, the associated input data208and/or output data209from host memory204. In one embodiment, the request and the associated input data208are deleted from request queue206when the request is extracted by request unit214, while the associated output data209is deleted by the associated thread once the thread has finished with the contents within output data209.

Processing of Security Operations by Coprocessor212

FIG. 10illustrates a flow diagram for the processing of requests by coprocessor212, according to embodiments of the present invention. Method1000commences with polling of doorbell register220by request unit214, at process block1002. This polling of doorbell register220is shown in one process block. However, embodiments of the present invention are not so limited, as this polling of doorbell register220can occur on a periodic basis such that request unit214can be performing this polling while the functionality illustrated in other process blocks is occurring. For example, this polling by request unit214can be executing at the same time that one of execution units216–217are processing the requests (in process block1012illustrated below). In one embodiment, request unit214polls doorbell register220every clock cycle.

Additionally, request unit214determines whether request queue206includes requests based on the value stored in doorbell register220, at process decision block1004. Request unit214can access a number of memory locations, local to coprocessor212to determine the size and location of request queue206. A first memory location is the base address of request queue206, and a second memory location is the length of request queue206. In one embodiment, these memory locations are registers within coprocessor212. In an embodiment, request processing unit234sets these memory locations to appropriate values during initialization.

In one embodiment, the value stored into doorbell register220by request processing unit234is the number of requests that were added to request queue206(not the total number of requests in request queue206). Accordingly, upon determining that request queue206does not include requests, request unit214polls doorbell register220again, at process block1002. In contrast, upon determining that request queue206does include requests, request unit214updates a counter with the total number of requests in request queue206, at process block1006. In one embodiment, this counter is local memory within coprocessor212, such as a register. To help illustrate the updating of this counter, if the value stored in this counter is 25 and doorbell register220has a value of five, request unit214adds the two values together (for a total of 30) and stores the result in the counter. Additionally, request unit214resets the value stored in doorbell register220to zero, at process block1008.

However, embodiments of the present invention are not so limited, as other techniques can be employed in tracking the number of requests in request queue206. For example, in one embodiment, one memory location is used to store the total number of requests within process queue206that can be updated by both request processing unit234and request unit214, using for example semaphores to allow for updating of a single memory location by multiple units.

At process block1006, request unit214determines whether one of the number of execution units216–217is able to process the requests and/or space is available within request buffer222within coprocessor212to store requests extracted from request queue206. In particular, in one embodiment, coprocessor212includes request buffer222to store requests received from request queue206that are to be processed by one of the execution units216–217. As in the described embodiment illustrates inFIG. 8, each of the number of execution units216–217includes or has access to the microcode that enables such units to execute a number of different security operations, including, but not limited to, those described above (in conjunction with the description of the different requests). In other words, a given one of execution units216–217is not limited to a given function, such as a hash operation, while a one of the other execution units216–217is limited to the generation of keys for security operations. Rather, each of the number of execution units216–217is able to perform a number of different primitive and macro security operations.

Upon determining that there is no available buffer space within coprocessor212for storage of the requests locally and/or available execution units216–217to process such requests, request unit214continues checking for this available buffer space or execution units216–217, at process decision block1010. In one embodiment, request unit214may determine such availability from signals received from execution units216–217or other control circuitry within coprocessor212. Conversely, upon determining that there is available buffer space within coprocessor212for storage of the requests locally and/or available execution units216–217to process such requests, request unit214retrieves one to a number of requests from request queue206, at process block1012. In one embodiment, request unit214retrieves one to a number of such requests from request queue206using a DMA read operation.

Additionally, request unit214retrieves the associated input data208A–208I for these requests from host memory204, at process block1014. In one embodiment, input data208A–208I are contiguously stored in host memory204. In one such embodiment, request unit214retrieves this associated input data208A–208I using a single DMA read due to the contiguous storage of such data. Accordingly, only two DMA operations are needed for the transferring of multiple requests to coprocessor212, thereby increasing the overall processing speed for given security operations.

The units (including request unit214, execution units216–217and random number generator unit218) within coprocessor212process the requests, at process block1016. Request unit214distributes or administers these retrieved requests to execution units216–217and random number generator unit218. Because in one embodiment, each execution unit216–217is able to process any of the different types of security operations received, request unit214is able to transmit a request to the first of execution units216–217that is available for processing such requests.

For a given request, once one of execution units216–217completes the processing of the request, this execution unit216–217stores the result of this request in the location (one of output data209A–209I) in host memory204pointed to by result pointer212of the request (shown inFIG. 3), at process block1016. In addition to the actual result of the operation within the request, execution units216–217write a value within the completion code, such as a non-zero value, indicating that the request is complete. In one embodiment, execution units216–217write the results and the completion code by employing a DMA write operation. Accordingly, in one embodiment, three total DMA operations are required for a given request (including the DMA read for the request, the DMA read for the input data and the DMA write for the output result). Additionally, because multiple requests can be read from host memory204for a given DMA operation, the total number of DMA operations approaches approximately two, thereby limiting the overall bus transfers across system bus210, which can be costly in terms of the time for processing of the security operations.

Moreover, as illustrated, because coprocessor212includes a number of execution units that can each execute the different security operations and can do so independently of other security operations being processed by other execution units, these requests can be executed and/or completed (and outputting the result to host memory204) out-of-order in comparison to the order the requests were in within request queue206. For example, a first request could include a key generation operation for a first SSL operation, while a second request could include a modular exponentiation operation for second SSL session, such that the first request is stored in and extracted from request queue206prior to the second request. Typically the second request is processed more quickly than the first request by execution units216–217. Accordingly, the processing of the second request could complete prior to the processing of the first request even though the first request was transmitted to coprocessor212first based on the order of the requests in request queue206.

Thus, one embodiment is described in which the requests are treated as independent of each other by the hardware. If there is a dependency that requires a particular order of completion between any requests, that order is enforced by the software in this embodiment. However, alternative embodiments include hardware that enforces in-order completion of the requests.

Memory described herein includes a machine-readable medium on which is stored a set of instructions (i.e., software) embodying any one, or all, of the methodologies described herein. Software can reside, completely or at least partially, within this memory and/or within processors described herein. For the purposes of this specification, the term “machine-readable medium” shall be taken to include any mechanism that provides (i.e., stores and/or transmits) information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media; optical storage media, flash memory devices, electrical, optical, acoustical, or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), etc.

Thus, a method and apparatus for processing security operations have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. For example, in alternative embodiments, the host processor could employ interrupts to communicate with the security coprocessor, while allowing the security coprocessor to employ DMA operations to communicate with the host memory. Alternatively, the security coprocessor could employ interrupts for its communication with the host processor, while the host processor employs DMA operations for its communications with the coprocessor. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.