Command type filtering based on per-command filtering indicators

Abstract

The auxiliary processor dynamically determines, for each command, whether the command retrieved by the auxiliary processor should be processed by the auxiliary processor. The auxiliary processor retrieves a command request from a requestor. The command request includes at least one filtering indicator indicating at least one valid command type for processing by the auxiliary processor for the requestor. The auxiliary processor uses the at least one filtering indicator to determine whether a command in the command request is valid for processing by the auxiliary processor for the requestor. Based on a determination that the command is valid for processing by the auxiliary processor, the command is processed by the auxiliary processor.

Description

[Technical Field]

[0001] One or more aspects relate generally to facilitating processing within a computing environment, and more particularly, to facilitating processing related to command processing within a computing environment. [Background technology]

[0002] Computing environments often include different types of processors to enhance processing. As an example, a computing environment may include one or more central processing units, considered main processors, and one or more auxiliary processors, considered subordinate to the central processing units. An auxiliary processor typically performs a specific type of task. For example, a specific example of an auxiliary processor is a crypto card used to perform cryptographic operations.

[0003] An example of a cryptographic card offered by International Business Machines Corporation of Armonk, New York, is the channel-attached Crypto Express card. The Crypto Express card is defined to support multiple types of commands, such as commands that use cryptographic keys (called secure key commands), commands that use clear keys (called clear key commands), hash commands, query commands, random number generator commands, and more. Additionally, the Crypto Express card is designed to support multiple modes, including, for example, Common Cryptographic Architecture (CCA) mode, accelerator mode, and Enterprise Public Key Cryptography Standards (PKCS) mode (also known as XCP / EP11-Enterprise PKSC#11 mode). Each mode is configured to handle a specific type of command.

[0004] The Crypto Express cards can be configured to operate in one of a number of different modes for the duration of the booted machine configuration. Thus, if a customer wants to use different modes, the computing environment will include at least that number of cards for the different modes, each card configured in a different mode and capable of processing the particular type of commands defined for that mode. Summary of the Invention

[0005] Shortcomings of the prior art are addressed and additional advantages are provided by providing a computer program product for facilitating processing within a computing environment. The computer program product includes one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media for performing a method. The method includes dynamically determining, by the auxiliary processor, whether a command retrieved by the auxiliary processor should be processed by the auxiliary processor. The dynamically determining is performed on a command-by-command basis and includes retrieving a command request for a requestor by the auxiliary processor. The command request includes at least one filtering indicator indicating at least one valid command type for processing by the auxiliary processor for the requestor. The auxiliary processor uses the at least one filtering indicator to determine whether a command in the command request is valid for processing by the auxiliary processor for the requestor. The auxiliary processor processes the command based on a determination that the command is valid for processing by the auxiliary processor for the requestor.

[0006] Flexibility is provided in command processing by dynamically determining, on a command-by-command basis, whether an auxiliary processor can process a particular command. A command is either valid or invalid at the time of command processing, so a program does not have to switch between various auxiliary processors to execute different types of commands. This reduces program complexity, provides more efficient code, and improves code execution time and performance.

[0007] In one embodiment, the auxiliary processor is configured in one mode and, by dynamically determining, the auxiliary processor can operate differently from the one mode in which it is configured. For example, in one example, the auxiliary processor configured in one mode can process a set of commands; however, the auxiliary processor operates differently in that it processes a reduced set of the commands. The auxiliary processor can dynamically switch filtering modes on a per-command basis because command type filtering is provided on a per-command basis. This allows a particular auxiliary processor to be used in different modes. For example, the auxiliary processor can be configured in one mode, but can operate in a different mode without reconfiguring the auxiliary processor. Furthermore, allowing the auxiliary processor to operate in different modes saves the cost of additional auxiliary processors and provides flexibility within the system.

[0008] In one embodiment, at least one filtering indicator is set on a per-command basis. Providing per-command filtering indicators provides flexibility in command processing, as well as reduces code complexity, improves performance, and reduces costs by requiring fewer auxiliary processors.

[0009] In one embodiment, at least one filtering indicator is set based on a computing policy corresponding to the source of the command request, such that certain license attributes, permissions, and / or customer requirements can be taken into account in processing the command.

[0010] In one embodiment, the at least one filtering indicator includes a stateless command type indicator, and commands determined to be stateless command type commands based on the stateless command type indicator being set to a value of one are valid for processing by the auxiliary processor for the requestor, and other command type commands are invalid for processing by the auxiliary processor for the requestor. Furthermore, in one embodiment, other command type commands are further deemed valid for processing by the auxiliary processor for the requestor based on the stateless command type indicator being set to another value. This allows an auxiliary processor configured in a mode that provides a full set of commands to provide selective commands, instead of the full set of commands, to one or more requestors and provide the full set of commands to other requestors. This provides flexibility, reduced code complexity, improved performance, and reduced cost because fewer auxiliary processors may be required.

[0011] In one embodiment, the processing includes preparing a response including results of processing the command, the response to be sent to the requestor. Further, in one embodiment, based on a determination that the command is invalid for processing by the auxiliary processor for the requestor, an error response indicating the error is prepared, the error response to be sent to the requestor. The error response notifies the requestor that the command is an invalid command type.

[0012] In one example, the auxiliary processor is a cryptographic card.

[0013] According to one aspect, a computer program product for facilitating processing within a computing environment is provided, the computer program product including one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media for performing a method, the method including: dynamically determining, by an auxiliary processor, whether a command obtained by the auxiliary processor should be processed by the auxiliary processor, the dynamically determining being performed on a command-by-command basis, the dynamically determining including obtaining, by the auxiliary processor, a command request for a requestor, the command request including at least one filtering indicator indicating at least one valid command type for processing by the auxiliary processor for the requestor; determining, by the auxiliary processor using the at least one filtering indicator, whether a command in the command request is valid for processing by the auxiliary processor for the requestor; and processing the command by the auxiliary processor based on a determination that the command is valid for processing by the auxiliary processor for the requestor.

[0014] According to another aspect, a computer system for facilitating processing within a computing environment is provided, the computer system including a memory and at least one processor in communication with the memory, the computer system configured to perform a method, the method including: dynamically determining, by an auxiliary processor, whether a command obtained by the auxiliary processor should be processed by the auxiliary processor, the dynamically determining being performed on a command-by-command basis, the dynamically determining including obtaining, by the auxiliary processor, a command request for a requestor, the command request including at least one filtering indicator indicating at least one valid command type for processing by the auxiliary processor for the requestor; determining, by the auxiliary processor using the at least one filtering indicator, whether a command in the command request is valid for processing by the auxiliary processor for the requestor; and processing the command by the auxiliary processor based on a determination that the command is valid for processing by the auxiliary processor for the requestor.

[0015] According to another aspect, a computer-implemented method for facilitating processing within a computing environment is provided, the computer-implemented method including: dynamically determining, by an auxiliary processor, whether a command obtained by the auxiliary processor should be processed by the auxiliary processor, the dynamically determining being performed on a command-by-command basis; obtaining, by the auxiliary processor, a command request for a requestor, the command request including at least one filtering indicator indicating at least one valid command type for processing by the auxiliary processor for the requestor; determining, by the auxiliary processor using the at least one filtering indicator, whether a command in the command request is valid for processing by the auxiliary processor for the requestor; and processing the command by the auxiliary processor based on a determination that the command is valid for processing by the auxiliary processor for the requestor.

[0016] Computer-implemented methods and systems relating to one or more aspects are further described and claimed herein. Additionally, services relating to one or more aspects may be further described and claimed herein.

[0017] Additional features and advantages are realized by the techniques described herein. Other embodiments and aspects are described in detail herein and are considered a part of the claimed aspects.

[0018] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the following drawings, in which: [Brief explanation of the drawings]

[0019] [Figure 1A] FIG. 1 illustrates an example computing environment for incorporating and using one or more aspects of the present invention. [Figure 1B]FIG. 1 illustrates another example of a computing environment for incorporating and using one or more aspects of the present invention. [Figure 2A] FIG. 10 illustrates an example of a process assist processor queue instruction in accordance with one or more aspects of the present invention. [Figure 2B] FIG. 10 illustrates an example of a process assist processor queue instruction in accordance with one or more aspects of the present invention. [Figure 2C] FIG. 10 illustrates an example of a process assist processor queue instruction in accordance with one or more aspects of the present invention. [Figure 2D] FIG. 10 illustrates an example of a process assist processor queue instruction in accordance with one or more aspects of the present invention. [Figure 3A] FIG. 10 illustrates an example of an auxiliary processor command request message in accordance with one or more aspects of the present invention. [Figure 3B] FIG. 1 illustrates an example of a Demand Connection Programming Request Block (CPRB) in accordance with one or more aspects of the present invention. [Figure 3C] FIG. 10 illustrates an example of an auxiliary processor command response message in accordance with one or more aspects of the present invention. [Figure 3D] FIG. 1 illustrates an example of a response connection programming request block (CPRB) in accordance with one or more aspects of the present invention. [Figure 4] FIG. 2 illustrates an example flow for providing per-command filtering in accordance with one or more aspects of the present invention. [Figure 5A] FIG. 1 illustrates one embodiment of aspects relating to facilitating processing within a computing environment in accordance with one or more aspects of the present invention. [Figure 5B] FIG. 1 illustrates one embodiment of aspects relating to facilitating processing within a computing environment in accordance with one or more aspects of the present invention. [Figure 6A] FIG. 1 illustrates an example computing environment for incorporating and using one or more aspects of the present invention. [Figure 6B] FIG. 1 illustrates another example of a computing environment for incorporating and using one or more aspects of the present invention. [Figure 6C] FIG. 6C illustrates an example of further details of the memory of FIG. 6B, in accordance with one or more embodiments of the present invention. [Figure 6D] FIG. 6C illustrates another example of further details of the memory of FIG. 6B, in accordance with one or more embodiments of the present invention. [Figure 7A] FIG. 1 illustrates another example of a computing environment for incorporating and using one or more aspects of the present invention. [Figure 7B] 7B illustrates further details of the memory of FIG. 7A in accordance with one or more embodiments of the present invention. [Figure 8] FIG. 1 illustrates one embodiment of a cloud computing environment, in accordance with one or more aspects of the present invention. [Figure 9] FIG. 2 illustrates an example of an abstraction model layer, in accordance with one or more aspects of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0020] According to one or more aspects of the present invention, a filtering capability is provided that enables an auxiliary processor, such as a crypto card, to dynamically determine, on a per-command basis, whether a command retrieved by the auxiliary processor should be executed by the auxiliary processor. For example, one or more per-command filtering indicators (e.g., selected command type filtering indicators) are used to determine whether a received command is a valid command type specified by the per-command filtering indicators and therefore should be executed by the auxiliary processor. In one embodiment, the one or more per-command filtering indicators are set on a per-command basis based on a computing policy associated with the command requestor. Thus, a command issued by one requestor may be a valid command type for execution as specified by the per-command filtering indicators set based on the requestor's computing policy, while a command issued by another requestor may be invalid.

[0021] In one or more aspects, the auxiliary processor may be configured in a particular processing mode (e.g., Common Cryptographic Architecture (CCA) mode, also known as coprocessor mode), but filtering may be applied such that the auxiliary processor operates differently from the configured mode without being reconfigured. For example, based on filtering, such as selected command type filtering, commands of one or more selected command types (e.g., stateless command type commands) may be executed by the auxiliary processor, and the selected command types may be fewer than all command types supported by the configured mode. That is, commands that may be supported in the configured processing mode (e.g., non-stateless command type commands) may not be executed by the auxiliary processor, in certain cases, when selected command type filtering is applied, if the command is not of a selected command type (e.g., stateless command type commands).

[0022] In one example, the filtering technique applied is a stateless command type filtering technique, and an auxiliary processor configured in one mode (e.g., coprocessor mode) can be used to execute either the full set of command types supported in that mode, or a reduced set of command types (e.g., only stateless command type commands). However, while the stateless command type filtering technique is described herein as one example, other command type filtering techniques and / or other filtering techniques may be applied. For example, a master key filtering technique may be used, in which the selected command types are master key management key commands. As another example, filtering may be implemented using policy-imposed use case restrictions. For example, if selected command access is priced differently than general cryptographic command access, a filter may be imposed on purchased use cases. Further levels of filtering may be based on performance service contracts, in which commands are marked with a higher or lower service response performance priority based on the purchased performance. Other filtering techniques may also be used. The application of each filtering technique is permitted without reconfiguring the auxiliary processor into a different mode. The filtering techniques may be used in conjunction with each other or separately from each other. Many examples are possible.

[0023] One embodiment of a computing environment for incorporating and using one or more aspects of the present invention is described with reference to FIG. 1A. In one example, computing environment 100 includes at least one central processing unit 102 and at least one auxiliary processor (AP) 104, each of which is coupled to at least a portion of memory referred to as system memory 106. As one example, system memory 106 includes hardware system areas that are indirectly accessible and invisible to programs executing on the central processing unit. (Indirectly accessible is used herein to mean that the hardware system areas, or auxiliary processor queues (described below) stored therein, are accessible only by certain limited instructions and are not otherwise accessible (e.g., cannot be loaded into, programs do not know the address, etc.).) Located within the system memory are one or more auxiliary processor queues 108. These queues are not directly visible to user programs and are instead considered part of the machine (i.e., the machine including the central processing unit, system memory, and auxiliary processors). The central processing unit has access to the queue in system memory, for example, by issuing instructions to place requests on the queue and / or remove responses from the queue. However, the auxiliary processor has direct access to the queue, for example, through the transport layer 110 (e.g., i390CO), and is responsible for removing requests from the queue, processing the requests, and placing responses to the requests on the queue.

[0024] Another embodiment of a computing environment incorporating and using one or more aspects of the present invention is described with reference to FIG. 1B. In this embodiment, the machine includes virtualization support and has at least one host central processing unit 150 that includes multiple guests 152 (e.g., guest operating systems and / or guest programs). The host central processing unit is coupled to at least a portion of memory referred to as system memory 154. In addition, there is at least one auxiliary processor 156, which is also coupled to system memory 154, for example, via transport layer 160. In one example, system memory 154 includes a hardware system area, and one or more auxiliary processor queues 158 are located within the system memory.

[0025] As shown, there are different types of auxiliary processors, including, but not limited to, cryptographic cards or adapters. A specific example of a cryptographic card is the Crypto Express card offered by International Business Machines Corporation of Armonk, New York. While an exemplary cryptographic card is provided, other cryptographic cards offered by International Business Machines Corporation or other companies may incorporate and / or use one or more aspects of the present invention. Additionally, other types of auxiliary processors may incorporate and / or use one or more aspects of the present invention.

[0026] In one embodiment, an auxiliary processor, such as a cryptographic card (e.g., a Crypto Express card), supports multiple modes, including, by way of example and not limitation, a coprocessor mode, an accelerator mode, and an Enterprise Public Key Cryptography Standard (PKCS) mode (e.g., XCP / EP11-Enterprise PKCS#11). Additional, fewer, or other, or both modes may be supported in other examples. Each mode may have its own AP message structure and format.

[0027] As an example, an auxiliary processor message may consist of multiple data segments, which may not be adjacent to one another; instead, one or more may be interleaved. These data segments are referred to as scatter-gather data segments. In one example, the cryptographic card does not have direct access to the enqueued AP message, and a portion of the message (e.g., the bottom portion of the AP message) contains data that can be used by the cryptographic card, for example, to execute an AP command. Therefore, the AP command transport layer (e.g., transport layer 110, 160) copies the relevant data from the AP command request message, packages it into a format the cryptographic card understands (e.g., a crypto card command request message), and sends it to the cryptographic card. Similarly, after the AP command is executed by the cryptographic card, the AP command transport layer uses various portions of the AP command request message and the crypto card command response message to generate an AP command response message and sends it to the AP queue for later dequeuing by a program. Further details of the AP Command Request message and the AP Command Response message are described below, including aspects of the messages used in accordance with command type filtering of one or more aspects of the present invention.

[0028] According to one aspect of the present invention, an auxiliary processor (e.g., a cryptographic card) is designed that enables a machine hypervisor to request command type filtering according to a computing policy (e.g., a customer's license terms, permission requirements such as high availability requirements, or resource requirements, or both). Because customers have different computing policies associated with them (e.g., license terms, permissions, or resource requirements such as high availability requirements, or a combination thereof), not all types of commands may be available to a particular customer. Thus, according to one aspect of the present invention, command type filtering is provided so that a selected auxiliary processor (e.g., a cryptographic card configured for a particular mode (e.g., coprocessor mode)) can be used for customers with different computing policies, and therefore different permissions, without having to reconfigure the auxiliary processor to a different supported mode.

[0029] By way of example, in accordance with one or more aspects of the present invention, an AP Command Type Filtering Function (APFT) is provided that enables filtering of AP commands based on one or more selected AP command type filtering functions per command. In one example, the one or more selected AP command type filtering functions include a Stateless AP Command Filtering Function (SAPCF). Aspects of the AP command type filtering function and the Stateless AP Command Filtering Function are described herein with reference to a particular architecture, such as the z / Architecture® hardware architecture offered by International Business Machines Corporation of Armonk, New York. One embodiment of the z / Architecture hardware architecture is described in “z / Architecture Principles of Operation,” IBM Publication No. SA22-7832-12, 13th Edition, September 2019, which is incorporated herein by reference in its entirety. IBM and Z / ARCHITECTURE are registered trademarks of International Business Machines Corporation in at least one jurisdiction. However, the z / Architecture hardware architecture is merely one exemplary architecture. Aspects of the present invention may also be based on other architectures, including, but not limited to, the Intel x86 architecture, other architectures from International Business Machines Corporation, or architectures from other companies, or combinations thereof.

[0030] In one example, when the stateless AP command filtering feature is installed, the AP command type filtering feature is installed. To determine whether the stateless AP command filtering feature is installed, a process assist processor queue instruction is used in accordance with an aspect of the present invention.

[0031] One example of a process assist processor queue (PQAP) instruction is described with reference to FIG. 2A. As shown, in one example, a process assist processor queue instruction 200 includes an instruction code (opcode) 202 (e.g., bits 0-15 of a 32-bit instruction) that indicates a process operation for the assist processor queue. In one embodiment, the process assist processor queue instruction utilizes multiple general purpose registers, including general purpose registers 0, 1, and 2. The AP queue specified by the AP queue number (APQN) in general purpose register 0 is processed according to the function code specified in general purpose register 0. Examples of general purpose registers 0, 1, and 2 are described further below.

[0032] Referring to FIG. 2B, in one embodiment, general purpose register 0 (GR0) 210 is a 64-bit register that includes, for example, a function code (FC) 212 (e.g., bits 32-39) to indicate the selected function to be executed, a test function indicator (T) 214 (e.g., bit 40) used to indicate whether a mask of installed functions is available in general purpose register 2, and an auxiliary processor queue number (APQN) 216 (e.g., bits 48-63) that identifies the auxiliary processor queue (e.g., AP queue 108 (FIG. 1A), AP queue 158 (FIG. 1B)) to be processed according to the function code.

[0033] Based on the issuance of the process auxiliary processor queue instruction, the function code 212 may include one of several allowable codes, one example of which is code 00 Test AP Queue (TAPQ).

[0034] According to one or more aspects of the present invention, when a computing environment is in, for example, z / Architecture architecture mode and the APFT feature is installed, if a TAPQ feature code is specified (e.g., FC=00 in GR0), bit 40 of general register 0 is defined as the test feature bit (T) for the TAPQ feature. When T is 1, bits 0 through 31 of general register 2 are replaced with a mask of installed AP features and other related information, an example of which is described below. When T is zero, for example, indicating that the APFT feature is not installed, the result in general register 2 is restricted to, for example, bit positions 32 through 63, with bit positions 0 through 31 ignored and unchanged. In this case, the AT field and QD field (described below) are valid, and the other bit positions are stored as zero.

[0035] As shown, in addition to general purpose register 0, general purpose registers 1 and 2 are used by the process assist processor queue instructions, each of which is described further herein.

[0036] 2C, in one embodiment, general purpose register 1 (GR1) 220 is a 64-bit register that includes, for example, an auxiliary processor queue status word (APQSW) 222 (e.g., bits 32-63). At the completion of a process auxiliary processor queue instruction, unless otherwise noted for a particular function, the APQSW field contains the AP queue status word. The AP queue status word indicates, for example, the state of the AP queue at the time of completion of the instruction.

[0037] 2D, in one embodiment, general purpose register 2 (GR2) 230 is a 64-bit register that includes, for example, multiple fields. As described herein, in one embodiment, bit positions 0-31, when set, contain a mask of installed AP features and other related information. Example fields of GR2 according to one or more aspects of the present invention include, for example, the following:

[0038] Mode 232: When set, this field (e.g., bits 3-5) indicates multiple possible AP mode capabilities. For example, when D (e.g., bit 3) is 1, the specified AP provides coprocessor mode capabilities, when A (e.g., bit 4) is 1, the specified AP provides accelerator mode capabilities, and when X (e.g., bit 5) is 1, the specified AP provides XCP mode capabilities.

[0039] SL234: When this field (e.g., bit 7) is 1, the Stateless AP Command Filtering Function (SAPCF) of one or more aspects of the present invention is installed. The SAPCF function is, for example, the PCI-X (Peripheral Component Interconnect Extensions) Crypto Device Function, which, in one embodiment, is installed in z / Architecture architecture mode.

[0040] Other features and / or information relating to one or more features that may be supported by the computing environment may be indicated by one or more bits of the mask, for example, in bits 0-31.

[0041] Auxiliary Processor Type (AT) 236: This field (eg, bit positions 32-39) contains example valid AP type values, eg, in the range 0-255, indicating various AP types.

[0042] Number of AP Queue Entries (QD) 240: The number of queue entries for each AP queue in the configuration. QD is, for example, a value in the range of 0 to 31, representing the number of queue entries in the decimal range of 1 to 32, for example.

[0043] In one example, the installed feature information returned in general register 2 applies to all APs of the same AP type and of the same configuration mode (in the case of unified APs (e.g., AP type 10 and above)). The installed feature information persists, in one example, at least until the next subsystem reset. Features can be added simultaneously. Features may or may not be removed simultaneously when the last AP of an AP type is deconfigured.

[0044] General register 2 is modified as defined when a TAPQ function completes, e.g., with status code 0 (successful completion), or with status code 3 and a response code, e.g., 02-05 (unexpected condition, e.g., AP queue reset in progress, AP deconfiguration, AP checkstop, AP busy). Otherwise, general register 2 is not modified.

[0045] Although certain fields, field locations, field sizes, bits, and field or bit values ​​are described herein for the process assist processor queue instruction and associated registers in one embodiment, other fields, field locations, field sizes, bits, field or bit values, or combinations thereof, may be used without departing from the spirit of one or more aspects of the present invention. Each field and / or bit of a general-purpose register not described herein may be blank, have a predefined value (e.g., zero), or contain a value that may be ignored in one embodiment, or a combination thereof. Many possibilities exist.

[0046] According to one or more aspects, an auxiliary processor (e.g., a crypto card) has logic that recognizes attributes of different types of commands. The different types of commands are provided, in one embodiment, by a hypervisor. The hypervisor determines a set of command type tags based, for example, on a set of customers that can receive command requests. For example, the types of commands that can be represented by the set of command type tags are based, for example, on the computing policies (e.g., license terms, permissions, resource requirements such as high availability requirements, etc.) of the customers that can receive the command requests.

[0047] In one example, a command has an associated set of tags (e.g., policy or filtering tags) that represent attributes of the command. A command may have multiple tags associated with multiple command types, and therefore the set of tags includes one or more tags depending on the command type with which the command is associated. For example, a command may have a stateless command type tag to indicate that the command is a valid stateless command type command, a master key command type tag to indicate that the command is a valid master key command type command, etc. An indication of the set of command type tags is obtained (e.g., provided, received, retrieved, etc.) by the auxiliary processor. In one example, the auxiliary processor receives a set of command type tags that includes a tag for a secure key command type command (e.g., used to disable secure key commands when requested by the caller) and a tag for a stateless command type command. In other embodiments, the hypervisor provides other tags for other filtering techniques, such as other command type filtering techniques. Many possibilities exist.

[0048] Additionally, in one embodiment, the command request is configured to include one or more filtering indicators, such as one or more command type filtering indicators used to perform per-command filtering in accordance with one or more aspects of the present invention. Further details regarding selected command type filtering indicators included in the command request are described with reference to Figures 3A-3B.

[0049] 3A, in one example, an AP command request message 300 includes a header 302, a subheader 304, and multiple packets 306-312. In one example, one or more of the packets (e.g., one or more of packets-1 308-310) are configured to provide commands, and one or more of the packets (e.g., packet-2 312) are configured to provide input data. One of the packets includes a request connection programming request block (CPRB) 308 that includes one or more filtering indicators associated with command type filtering, in accordance with one aspect of the present invention.

[0050] For example, as shown in FIG. 3B, the request CPRB 308 includes an AP command filter mask 320 that includes one or more command type filtering indicators. One example of a command type filtering indicator is a stateless command type indicator 322. This indicator indicates whether the allowed command set is for stateless command type commands (e.g., indicator 322, such as a selected bit set to 1) or for the full command set (e.g., indicator 322 set to 0). Other indicators, flags, bits, etc. may be included in the request CPRB 308 to indicate other types of commands that may be filtered. For example, another indicator could indicate filtering based on a master key. Many other examples are possible.

[0051] In response to the message, a response is provided, in one example, in the form of an AP command response message, an example of which is shown in Figure 3C. As shown, AP command response message 330 includes, for example, a header 332, a subheader 334, and multiple packets 336-340. One of the packets includes a response CPRB 336 that contains a response to the request and may indicate an error, in accordance with one aspect of the present invention.

[0052] For example, as shown in Figure 3D, the response CPRB 336 includes an error indication that may include an error code 350 (e.g., CPRB return_code / reason_code) to report that the command requested by the customer is not allowed by a defined set of command type tags (e.g., imposed by the hypervisor or another entity).

[0053] As described herein, command request / response messages are used in accordance with one aspect of the present invention to perform command type filtering on a per-command basis. Further details regarding command type filtering on a per-command basis are described with reference to Figure 4. In the example of Figure 4, the computing environment is a cloud environment; however, in other embodiments, the computing environment is a non-cloud environment.

[0054] Aspects of the present invention are not limited to any particular computing environment.

[0055] Further, in the example of Figure 4, the auxiliary processor is a cryptographic card. However, filtering may be used by other auxiliary processors, and the cryptographic card is only one example.

[0056] 4, in one embodiment, a cryptographic request is originated (step 420) by a requestor such as a guest 400 (e.g., a guest application or guest operating system in a cloud environment). In one example, an AP command request message 300 is encoded and provided to a hypervisor 402.

[0057] A cryptographic request is obtained (e.g., received, retrieved, provided, etc.) from guest 400 by hypervisor 402 and processed (step 422). According to one aspect of the present invention, the hypervisor adds (or sets) one or more filtering indicators, such as a command type filtering indicator, to the request based on request policy 414 (e.g., cloud request policy). Request policy 414 includes, for example, an indication of the allowable command types for each requestor (e.g., guest, caller, customer) that should be processed for the requestor based on the requestor's computing policy (e.g., license terms, resource requirements such as high availability requirements, and / or permissions) provided by account configuration 416 (e.g., cloud account configuration).

[0058] As an example, the hypervisor 402 determines, based on a request policy (based on the guest's computing policy), whether the stateless command type indicator 322 (or another filtering indicator) should be set to a selected value, such as 1 (e.g., a reduced set of allowed commands, such as only stateless command type commands allowed), or to another selected value, such as zero (e.g., the full set of allowed commands). The hypervisor sets the stateless command type indicator 322 (or, in other examples, other filtering indicators, or both) based on the determination.

[0059] The hypervisor 402 provides the modified request message (i.e., the request message with the filtering indicator set) to the auxiliary processor (e.g., the cryptographic card 406). For example, the hypervisor 402 sends or forwards the request message to the auxiliary processor, e.g., via the system bus 404, or the auxiliary processor otherwise obtains (e.g., retrieves) the request message via the system bus 404.

[0060] In this example, an auxiliary processor, such as cryptographic card 406, processes the request (step 424). Processing includes, for example, determining whether the request is authorized (query 426) using a command type filtering indicator included in the request. For example, if the stateless command type indicator 322 in the received request message is set to a value of 1, e.g., 1, indicating that the requestor (e.g., a guest) is authorized for stateless command type commands, and the command is a stateless command type command as indicated by one or more tags (e.g., policy or filtering tags) associated with the command, the request is valid. However, if the command is a non-stateless command type command and indicator 322 is set to a value of 1 (e.g., 1), the command is an invalid command for the requestor. Similarly, if indicator 322 is set to another value (e.g., zero), then the command is considered valid if it is included in the full command set as indicated by the command type policy tag.

[0061] If the request is permitted, the request is processed (e.g., the commanded action is performed) (step 428); otherwise, an error is provided (step 430). A response is processed by the auxiliary processor (e.g., a cryptographic card) (step 432), which may include placing the response in an AP command response message, which is sent to guest 400, for example, via a transport layer (e.g., transport layer 110, 160). The response may include, for example, a result of the processing, a condition code, a return code, a reason code, or an error indication (e.g., an error code in response CPRB 336), or a combination thereof. Guest 400 receives the response (step 434).

[0062] As described herein, in one embodiment, an auxiliary processor (e.g., a crypto card) receives a command request message from a requestor (e.g., a guest) and determines whether the command is allowed to be executed based on a set of hypervisor-imposed command type indicators (e.g., command type filtering indicators) in the CPRB request block. The set of hypervisor-imposed command type filtering indicators is used in per-command filtering. For example, if the auxiliary processor determines that the command is valid, for example, based on the command type filtering indicators, it executes the command and places the results in a command response message, which is sent to the caller. If the command is determined to be invalid, an error code is placed in the CPRB of the command response message and returned to the caller.

[0063] One or more aspects of the present invention are closely tied to computer technology and facilitate and improve performance of processing, including command processing, within a computing environment. Further details of one embodiment of an aspect related to facilitating processing within a computing environment are described with reference to Figures 5A-5B.

[0064] Referring to FIG. 5A, in one embodiment, the auxiliary processor dynamically determines whether a command obtained by the auxiliary processor should be processed by the auxiliary processor (500). The dynamic determining is performed on a command-by-command basis (502), and includes, for example, obtaining a command request for a requestor by the auxiliary processor (504). The command request includes at least one filtering indicator indicating at least one valid command type for processing by the auxiliary processor for the requestor (506). The auxiliary processor uses the at least one filtering indicator to determine whether a command in the command request is valid for processing by the auxiliary processor for the requestor (508). The auxiliary processor processes the command based on a determination that the command is valid for processing by the auxiliary processor for the requestor (510).

[0065] Flexibility is provided in command processing by dynamically determining, on a command-by-command basis, whether an auxiliary processor can process a particular command. A command is either valid or invalid at the time of command processing, so a program does not have to switch between various auxiliary processors to execute different types of commands. This reduces program complexity, provides more efficient code, and improves code execution time and performance.

[0066] In one embodiment, the auxiliary processor is configured in one mode, and by dynamically determining 512, the auxiliary processor can operate differently from the one mode for which it is configured. As an example, the auxiliary processor configured in one mode can process a set of commands 514, and the auxiliary processor operates differently in that it processes a reduced set of the set of commands 516. The auxiliary processor can dynamically switch filtering modes on a per-command basis because command type filtering is provided on a per-command basis. This allows a particular auxiliary processor to be used in different modes. For example, the auxiliary processor can be configured in one mode, but can operate in a different mode without reconfiguring the auxiliary processor. Furthermore, allowing the auxiliary processor to operate in different modes saves the cost of additional auxiliary processors and provides flexibility within the system.

[0067] 5B, in one embodiment, at least one filtering indicator is set on a per-command basis 520. Providing per-command filtering indicators provides flexibility in command processing, as well as reduced code complexity, improved performance, and reduced cost due to the need for fewer auxiliary processors.

[0068] In one embodiment, at least one filtering indicator is set 522 based on a computing policy corresponding to the origin of the command request, allowing specific license attributes, permissions, and / or customer requirements to be considered in command processing.

[0069] As an example, the at least one filtering indicator includes a stateless command type indicator (524). Based on the stateless command type indicator being set to a value of 1, commands determined to be stateless command type commands are valid for processing by the auxiliary processor for the requestor, and other command type commands are invalid for processing by the auxiliary processor for the requestor (526). Based on the stateless command type indicator being set to another value, other command type commands are further deemed valid for processing by the auxiliary processor for the requestor (528). This allows an auxiliary processor configured in a mode that provides a full set of commands to provide selective commands, instead of the full set of commands, to one or more requestors and provide the full set of commands to other requestors. This provides flexibility, reduced code complexity, improved performance, and reduced cost because fewer auxiliary processors may be required.

[0070] In one embodiment, the processing includes preparing a response including the results of processing the command, the response to be sent to the requestor 530. Further, in one example, based on a determination that the command is invalid for processing by the auxiliary processor for the requestor, an error response indicating the error is prepared, the error response to be sent to the requestor 532. The error response notifies the requestor that the command is an invalid command type.

[0071] Additionally, in one example, the auxiliary processor is a cryptographic card (534).

[0072] Other variations and embodiments are possible.

[0073] Command type filtering of one or more aspects of the present invention can be incorporated into and used in many computing environments. One exemplary computing environment is described with reference to FIG. 6A. As an example, the computing environment is based on the z / Architecture® hardware architecture offered by International Business Machines Corporation of Armonk, New York. However, the z / Architecture hardware architecture is only one exemplary architecture. The computing environment can also be based on other architectures, including, but not limited to, the Intel x86 architecture, other architectures from International Business Machines Corporation, or architectures from other companies, or combinations thereof.

[0074] 6A, computing environment 600 includes, for example, a computer system 602, shown in the form of a general-purpose computing device. Computer system 602 may include, but is not limited to, one or more processors or processing units 604 (e.g., central processing units (CPUs)), memory 606 (also known as, for example, system memory, main memory, main storage, central storage, or storage), and one or more input / output (I / O) interfaces 608, which are coupled together via one or more buses and / or other connections 610.

[0075] Bus 610 represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and without limitation, such architectures include Industry Standard Architecture (ISA), Micro Channel Architecture (MCA), Enhanced ISA (EISA), Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI).

[0076] The memory 606 may include a cache 612, such as, for example, a shared cache, which may be coupled to a local cache 614 of the processor 604. Additionally, the memory 606 may include one or more programs or applications 616, at least one operating system 618, and one or more computer-readable program instructions 620. The computer-readable program instructions 620 may be configured to perform the functions of embodiments of aspects of the present invention.

[0077] In one embodiment, memory 606 (e.g., at least the hardware system area of ​​memory 606) is coupled to one or more auxiliary processors 621 via one or more auxiliary processor buses 623, and in one or more embodiments, via an AP transport layer.

[0078] The computer system 602 can communicate with one or more external devices 630, such as, for example, a user terminal, a tape drive, a pointing device, a display, and one or more data storage devices 634, via the I / O interface 608. The data storage devices 634 can store one or more programs 636, one or more computer-readable program instructions 638, or data, or a combination thereof. The computer-readable program instructions can be configured to perform the functions of embodiments of aspects of the present invention.

[0079] The computer system 602 may also communicate with a network interface 632, for example via the I / O interface 608, which enables the computer system 602 to communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, to communicate with other computing devices or systems.

[0080] Computer system 602 may include and / or be coupled to removable / non-removable, volatile / non-volatile computer system storage media. For example, it may include and / or be coupled to non-removable, non-volatile magnetic media (commonly referred to as a "hard drive"), a magnetic disk drive for reading from and writing to removable, non-volatile magnetic disks (e.g., "floppy disks"), and / or an optical disk drive for reading from and writing to removable, non-volatile optical disks, such as CD-ROMs, DVD-ROMs, or other optical media. It should be understood that other hardware and / or software components may be used with computer system 602. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0081] Computer system 602 may be operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use with computer system 602 include, but are not limited to, personal computer (PC) systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0082] Another example of a computing environment for incorporating and using one or more aspects of the present invention is described below with reference to Figure 6B. As an example, the computing environment of Figure 6B may be based on the z / Architecture® hardware architecture offered by International Business Machines Corporation. However, the z / Architecture hardware architecture is only one example architecture. Again, the computing environment may be based on other architectures, including, but not limited to, the Intel x86 architecture, other architectures from International Business Machines Corporation, or architectures from other companies, or a combination thereof.

[0083] In one example, computing environment 650 includes a central electronic processing unit (CEC) 652. CEC 652 includes multiple components, such as, for example, one or more processors (also known as central processing units (CPUs)) 656 and memory 654 (also known as system memory, main memory, main storage, central storage, storage) coupled to an input / output (I / O) subsystem 658. Additionally, in one embodiment, memory 654 (e.g., at least the hardware system area of ​​memory 654) is coupled to one or more auxiliary processors 657 via one or more auxiliary processor buses, and in one or more embodiments, via an AP transport layer.

[0084] The I / O subsystem 658 may be part of or separate from the central electronic processing unit. It directs the flow of information between the main storage 654 and the input / output control unit 660 and input / output (I / O) devices 662 coupled to the central electronic processing unit.

[0085] Many types of I / O devices can be used. One particular type is a data storage device 664. The data storage device 664 can store one or more programs 666, one or more computer-readable program instructions 668, or data, or a combination thereof. The computer-readable program instructions can be configured to perform the functions of embodiments of aspects of the present invention.

[0086] The central electronic processing unit 652 may include and / or be coupled to removable / non-removable, volatile / non-volatile computer system storage media. For example, it may include and / or be coupled to non-removable, non-volatile magnetic media (commonly referred to as a "hard drive"), a magnetic disk drive for reading from and writing to removable, non-volatile magnetic disks (e.g., "floppy disks"), and / or an optical disk drive for reading from and writing to removable, non-volatile optical disks such as CD-ROMs, DVD-ROMs, or other optical media. It should be understood that other hardware and / or software components may be used in conjunction with the central electronic processing unit 652. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0087] Additionally, central electronic processing unit 652 may be operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use by central electronic processing unit 652 include, but are not limited to, personal computer (PC) systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0088] The central electronic processing unit 652, in one or more embodiments, provides logical partitioning and / or virtualization support. In one embodiment, as shown in FIG. 6C , the memory 654 includes, for example, one or more logical partitions 670, a hypervisor 672 that manages the logical partitions, and processor firmware 674. One example of a hypervisor 672 is the Processor Resource / System Manager (PR / SM) offered by International Business Machines Corporation of Armonk, New York. As used herein, firmware includes, for example, processor microcode. It includes, for example, hardware-level instructions and / or data structures used in implementing higher-level machine code. In one embodiment, it includes, for example, microcode that generally includes trusted software or proprietary code that is delivered as microcode specific to the underlying hardware and controls operating system access to system hardware.

[0089] Each logical partition 670 can function as a separate system. That is, each logical partition can independently reset, execute a guest operating system 676, such as the z / OS® operating system provided by International Business Machines Corporation of Armonk, New York, or other control code 678, such as Combined Function Control Code (CFCC), and operate with different programs 680. An operating system or application program running in a logical partition appears to have access to the entire system, but in fact, only a portion of it is available. While z / OS is provided as an example, other operating systems may be used in accordance with one or more aspects of the present invention.

[0090] Memory 654 is coupled to CPU 656 (FIG. 6B), which is a physical processor resource that can be assigned to a logical partition. For example, logical partition 670 includes one or more logical processors, each of which represents all or a portion of physical processor resource 656 that can be dynamically assigned to a logical partition.

[0091] Additionally, in further embodiments, the central electronic processing unit provides virtual machine support (with or without logical partitioning support). As shown in FIG. 6D, memory 654 of central electronic processing unit 652 includes, for example, one or more virtual machines 690, a virtual machine manager, such as hypervisor 692, that manages the virtual machines, and processor firmware 694. One example of hypervisor 692 is the z / VM® hypervisor offered by International Business Machines Corporation of Armonk, New York. A hypervisor is sometimes referred to as a host. z / OS and z / VM are trademarks or registered trademarks of International Business Machines Corporation in at least one jurisdiction.

[0092] The CPC's virtual machine support provides the ability to run multiple virtual machines 690, each running a different program 696 and capable of running a guest operating system 698, such as the Linux® operating system. Each virtual machine 690 can function as a separate system; that is, each virtual machine can be independently reset, run a guest operating system, and run a different program. An operating system or application program running in a virtual machine appears to have access to the entire system, but in reality, only a portion of it is available. While z / VM and Linux are provided as examples, other virtual machine managers and operating systems may be used in accordance with one or more aspects of the present invention. The registered trademark Linux® is used pursuant to a sublicense from the Linux Foundation, the exclusive licensee of Linus Torvalds, the worldwide owner of the trademark.

[0093] Another embodiment of a computing environment incorporating and using one or more aspects of the present invention is described with reference to FIG. 7A. In this example, computing environment 10 includes, for example, a native central processing unit (CPU) 12, memory 14, and one or more input / output devices or interfaces 16, coupled together, for example, via one or more buses 18 or other connections or both. By way of example, computing environment 10 may include a PowerPC® processor offered by International Business Machines Corporation of Armonk, New York, an HP Superdome with an Intel Itanium II processor offered by Hewlett-Packard Corporation of Palo Alto, California, or other machines based on architectures offered by International Business Machines Corporation, Hewlett-Packard, Intel Corporation, Oracle, etc., or combinations thereof. PowerPC is a trademark or registered trademark of International Business Machines Corporation in at least one jurisdiction. Intel and Itanium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

[0094] The native central processing unit 12 includes one or more native registers 20, such as one or more general purpose registers and / or one or more special purpose registers that are used during processing within the environment. These registers contain information that represents the state of the environment at any particular time.

[0095] Additionally, native central processing unit 12 executes instructions and code stored in memory 14. In one particular example, central processing unit executes emulator code 22 stored in memory 14. This code allows a computing environment configured with one architecture to emulate another architecture. For example, emulator code 22 allows machines based on architectures other than the z / Architecture hardware architecture, such as PowerPC processors, HP Superdome servers, etc., to emulate the z / Architecture hardware architecture and execute software and instructions developed based on the z / Architecture hardware architecture.

[0096] Further details related to emulator code 22 are described with reference to FIG. 7B . Guest instructions 30 stored in memory 14 include software instructions (e.g., related to machine instructions) developed to execute on an architecture other than that of native CPU 12. For example, guest instructions 30 may be designed to execute on a processor based on the z / Architecture hardware architecture, but are instead emulated on native CPU 12, which may be, for example, an Intel Itanium II processor. In one example, emulator code 22 includes an instruction fetching routine 32 for retrieving one or more guest instructions 30 from memory 14 and, optionally, providing local buffering for the retrieved instructions. It further includes an instruction conversion routine 34 for determining the type of the retrieved guest instruction and converting the guest instruction to one or more corresponding native instructions 36. This conversion includes, for example, identifying a function to be performed by the guest instruction and selecting a native instruction to perform that function.

[0097] Additionally, emulator code 22 includes an emulation control routine 40 for causing native instructions to be executed. Emulation control routine 40 may cause native CPU 12 to execute a routine of native instructions that emulates one or more previously fetched guest instructions, and, upon completion of such execution, return control to an instruction fetch routine to emulate the fetch of the next guest instruction or group of guest instructions. Execution of native instructions 36 may include loading data from memory 14 into a register, storing data from a register back to memory, or performing some type of arithmetic or logical operation as determined by a conversion routine.

[0098] Each routine may be implemented, for example, in software, which is stored in memory and executed by native central processing unit 12. In other examples, one or more of the routines or operations may be implemented in firmware, hardware, software, or a combination thereof. The emulated processor's registers may be emulated using the native CPU's registers 20 or by using locations in memory 14. In an embodiment, guest instructions 30, native instructions 36, and emulator code 22 may reside in the same memory or may be distributed among different memory devices.

[0099] Additionally, in one embodiment, computing environment 10 includes one or more auxiliary processors 15 coupled to memory 14. One or more auxiliary processors may be defined in one architecture and configured to emulate another architecture. For example, the auxiliary processor may obtain guest commands for the architecture being emulated, translate the guest commands into native commands for one architecture, and execute the native commands.

[0100] The computing environments described above are merely examples of computing environments that may be used. Other environments, including but not limited to, non-partitioned, partitioned, cloud, or emulated environments, or combinations thereof, may also be used, and embodiments are not limited to any one environment. While various examples of computing environments are described herein, one or more aspects of the present invention may be used in many types of environments. The computing environments provided herein are merely examples.

[0101] Each computing environment may be configured to include one or more aspects of the present invention, for example, each may be configured in accordance with one or more aspects of the present invention for per-command filtering.

[0102] As described herein, in one or more aspects, per-command command type filtering is provided. Many filtering techniques, including many command type filtering techniques, can be used. In one particular example, stateless command type filtering is provided. With this filtering, in one example, if the stateless command filtering feature is set, for example, to zero, the stateless command filtering feature is not installed and the auxiliary processor (e.g., crypto card) allows commands supported by the auxiliary processor to be executed; otherwise, the stateless command filtering feature is installed and whether a command is executed by the auxiliary processor depends at least on the value of a hypervisor-imposed set of command type filtering indicators in the command request. Example embodiments including a stateless command type indicator in a command request message are described below.

[0103] If the stateless command type indicator (e.g., indicator 322) is set to zero in a command request message (e.g., message 300), the crypto card allows all of the commands supported by the crypto card to be executed. If the stateless command type indicator (e.g., indicator 322) is set to one in a command request message (e.g., message 300), the crypto card does not allow all of the commands supported by the crypto card to be executed. If the command in the command request message is a stateless command type command, the command is executed. If the command in the command request message is not a stateless command type command, the command is rejected with an error code in the CPRB (e.g., response CPRB 336) of the command response message (e.g., message 330).

[0104] In one or more aspects, the configured mode of the crypto card (e.g., coprocessor mode) may be used to provide either stateless command filtering (also referred to as non-secure key filtering mode, e.g., only stateless command type commands are processed) or another filtering mode with a reduced set of commands without configuring the crypto card in a new crypto card mode, such as accelerator mode. Filtering techniques may be used to filter a set of command type commands, such as stateless command type commands, or other command type commands, such as master key management commands, in other examples. This reduces the number of auxiliary processors to be purchased and managed.

[0105] Furthermore, one or more aspects of the present invention provide the ability to dynamically switch filtering modes on a per-command basis, with command type filtering being performed on a per-command basis. Therefore, each command may be enabled or disabled during command processing based on a command type flag value (e.g., a command type filtering indicator). A program does not need to switch between various crypto card modes to execute different sets of filtering commands. Therefore, the complexity of managing and using the number of crypto cards remains the same regardless of the number of filtering modes supported. This reduction in program complexity also translates into more efficient code, improving code execution time and performance.

[0106] In a further embodiment, to provide filtering functionality, a list of actual command codes or mnemonics is used along with the function codes or mnemonics to convey the command codes and / or function codes that are supported.

[0107] While various embodiments are described herein, many variations and other embodiments are possible without departing from the spirit of the aspects of the present invention. It should be noted that, unless otherwise contradictory, each aspect or feature described herein, and variations thereof, can be combined with any other aspect or feature.

[0108] One or more aspects may relate to cloud computing.

[0109] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that practice of the teachings detailed herein is not limited to cloud computing environments. Rather, embodiments of the present invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0110] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with the service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0111] The features are as follows:

[0112] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capabilities such as server time and network storage automatically as needed without the need for human interaction with the service provider.

[0113] Pervasive Network Access: Functionality is available across the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0114] Resource Pooling: A provider's computing resources are pooled to serve a large number of consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated according to demand. Consumers typically have no control or knowledge over the exact location of the resources provided, but there is a sense of location independence in that they may be able to specify location at a higher level of abstraction (e.g., country, state, or data center).

[0115] Rapid Elasticity: Capabilities can be quickly and elastically provisioned and quickly scaled out, and quickly released and quickly scaled in, sometimes automatically. To the consumer, the capabilities available for provisioning often appear unlimited and can be purchased in any quantity at any time.

[0116] Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at an abstraction level appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of utilized services.

[0117] The service model is as follows:

[0118] Software as a Service (SaaS): The functionality offered to the consumer is the use of the provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, except for the possibility of limited user-specific application configuration settings.

[0119] Platform as a Service (PaaS): The capability offered to the consumer is the deployment of consumer-created or acquired applications created using programming languages ​​and tools supported by the provider onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does control the deployed applications and, in some cases, the application hosting environment configuration.

[0120] Infrastructure as a Service (IaaS): The functionality provided to the consumer is the provisioning of processing, storage, network, and other basic computing resources, upon which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does control the operating system, storage, deployed applications, and in some cases, limited control over selected networking components (e.g., host firewalls).

[0121] The deployment model is as follows:

[0122] Private Cloud: The cloud infrastructure is operated solely for the organization. The cloud infrastructure may be managed by the organization or a third party and may reside on-premises or off-premises.

[0123] Community Cloud: Cloud infrastructure is shared by several organizations to support a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). The cloud infrastructure may be managed by the organization or a third party and may reside on-premises or off-premises.

[0124] Public Cloud: Cloud infrastructure is made available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0125] Hybrid Cloud: A cloud infrastructure is a composite of two or more clouds (private, community, or public) that remain distinct entities but are joined by standard or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0126] Cloud computing environments are service-oriented with an emphasis on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0127] Referring now to FIG. 8, an exemplary cloud computing environment 50 is shown. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 52 with which local computing devices used by cloud consumers, such as a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, or an automobile computer system 54N, or combinations thereof, can communicate. The nodes 52 can communicate with each other. The nodes 52 may be physically or virtually grouped in one or more networks, such as the private, community, public, or hybrid clouds described above, or combinations thereof (not shown). This enables the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service, eliminating the need for cloud consumers to maintain resources on their local computing devices. It should be understood that the types of computing devices 54A-54N shown in FIG. 8 are intended to be exemplary only, and that computing node 52 and cloud computing environment 50 can communicate with any type of computerized device over any type of network and / or network-addressable connection (e.g., using a web browser).

[0128] Referring now to Figure 9, a set of functional abstraction layers provided by cloud computing environment 50 (Figure 8) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 9 are intended to be merely exemplary, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0129] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, RISC (reduced instruction set computer) architecture-based servers 62, servers 63, blade servers 64, storage devices 65, and networks and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0130] The virtualization layer 70 provides an abstraction layer that can comprise the following examples of virtual entities: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0131] In one example, the management layer 80 may provide the following functions: Resource provisioning 81 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and generates and sends bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection of data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 provides cloud computing resource allocation and management to ensure required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides proactive provisioning and procurement of cloud computing resources in anticipation of future demand according to SLAs.

[0132] The workload layer 90 provides examples of functionality that can utilize a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and command type filtering processing 96.

[0133] Aspects of the invention may be systems, methods, and / or computer program products at any possible level of integration of technical details, and may include a computer-readable storage medium (or media) having computer-readable program instructions for causing a processor to perform aspects of the invention.

[0134] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures with instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as being ephemeral signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through fiber optic cable), or electrical signals transmitted through wires.

[0135] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device over a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within the respective computing / processing device.

[0136] Computer-readable program instructions for carrying out operations of the present invention can be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk, C++, and the like, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions can execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

[0137] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0138] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus, such that the instructions, when executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, to produce a machine. These computer-readable program instructions may also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular way, such that the computer-readable storage medium on which the instructions are stored constitutes an article of manufacture containing instructions implementing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0139] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0140] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be accomplished as a single step that is executed concurrently, substantially concurrently, partially, or fully overlapping in time, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented in a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware instructions and computer instructions.

[0141] In addition to the above, one or more aspects may be provided, offered, deployed, managed, serviced, etc., by a service provider that provides management of a customer environment. For example, a service provider may create, maintain, support, etc., computer code and / or computer infrastructure that implements one or more aspects for one or more customers. In return, the service provider may receive payments from the customer, by way of example, under a subscription agreement or fee agreement or both. Additionally or alternatively, the service provider may receive payments from the sale of advertising content to one or more third parties.

[0142] In one aspect, an application may be deployed to perform one or more embodiments. In one example, deploying an application includes providing a computer infrastructure operable to perform one or more embodiments.

[0143] As a further aspect, a computing infrastructure can be deployed that includes integrating computer readable code into a computing system, the code in combination with the computing system being capable of executing one or more embodiments.

[0144] As a further aspect, there may be provided a process for integrating a computing infrastructure, comprising integrating computer-readable code into a computer system, the computer system including a computer-readable medium, the computer medium including one or more embodiments, the code in combination with the computer system capable of executing one or more embodiments.

[0145] Although various embodiments are described above, these are merely examples. For example, one or more embodiments may be implemented and used using computer environments of other architectures. Furthermore, different instructions, commands, or operations may be used. Additionally, different types of instructions or tags may be specified. Many variations are possible.

[0146] Various aspects are described herein. Furthermore, many variations are possible without departing from the scope of the present invention. It should be noted that, unless otherwise contradictory, each aspect or feature described herein, and variations thereof, can be combined with any other aspect or feature.

[0147] Additionally, other types of computing environments may be utilized to advantage. By way of example, a data processing system suitable for storing and / or executing executable program code may be utilized, including at least two processors coupled directly or indirectly to memory elements via a system bus. The memory elements may include, for example, local memory utilized during the actual execution of the program code, bulk storage, and cache memory that provides temporary storage of at least some program code to reduce the number of times the code must be retrieved from bulk storage during execution.

[0148] Input / output or I / O devices (including but not limited to keyboards, displays, pointing devices, DASDs, tapes, CDs, DVDs, thumb drives, and other memory media) may be coupled to the system either directly or through intervening I / O controllers. Network adapters may also be coupled to the system that enable the data processing system to be coupled to other data processing systems, remote printers, or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the available types of network adapters.

[0149] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used herein, specify the presence of stated features, integers, steps, operations, elements, or components, or combinations thereof, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or combinations thereof.

[0150] Corresponding structure, materials, acts, and equivalents of all means or step-plus-function elements in the following claims are intended to include any structure, material, or acts for performing a function, if any, in combination with other claimed elements as specifically claimed. The description of one or more embodiments has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosed form. Many modifications and variations will be apparent to those skilled in the art. The embodiments were chosen and described to best explain various aspects and practical applications and to enable those skilled in the art to recognize various embodiments with various modifications suited to the particular use intended.

Claims

1. 1. A computer program for facilitating processing in a computing environment, said computer program comprising: To the auxiliary processor, causing a dynamic determination of whether a command obtained by the auxiliary processor should be processed by the auxiliary processor, the dynamically determining being performed on a command-by-command basis, the dynamically determining including: the auxiliary processor; obtaining a command request for a requestor, the command request including at least one filtering indicator indicating at least one valid command type for processing by the auxiliary processor for the requestor, the at least one valid command type including each requestor's allowable command type to be processed for the requestor based on the requestor's computing policy; causing the auxiliary processor using the at least one filtering indicator to determine whether a command in the command request is valid for processing by the auxiliary processor for the requestor; causing the auxiliary processor to process the command based on a determination that the command is valid for processing by the auxiliary processor for the requestor; and said dynamically determining A computer program for executing the above.

2. 2. The computer program product of claim 1, wherein the auxiliary processor is configured in one mode, and wherein the dynamically determining allows the auxiliary processor to operate differently from the one mode in which it is configured.

3. 3. The computer program product of claim 2, wherein the auxiliary processor configured in one mode is capable of processing a set of commands, and the auxiliary processor operates differently in that it processes a reduced set of the set of commands.

4. The computer program product of claim 1 , wherein the at least one filtering indicator is set on a per command basis.

5. The computer program product of claim 4 , wherein the at least one filtering indicator is set based on a computing policy corresponding to the requestor of the command request.

6. 2. The computer program product of claim 1, wherein the at least one filtering indicator includes a stateless command type indicator, and wherein commands determined to be stateless command type commands based on the stateless command type indicator being set to a value of one are valid for processing by the auxiliary processor for the requestor, and other command type commands are invalid for processing by the auxiliary processor for the requestor.

7. 7. The computer program product of claim 6, wherein the other command type command is further considered valid for processing by the auxiliary processor for the requestor based on a stateless command type indicator being set to another value.

8. 2. The computer program product of claim 1, wherein the processing includes preparing a response including a result of the processing of the command, the response to be sent to the requestor.

9. 2. The computer program product of claim 1, further comprising: preparing an error response indicating an error based on a determination that the command is invalid for processing by the auxiliary processor for the requestor, the error response being sent to the requestor.

10. 10. The computer program product of claim 1, wherein the auxiliary processor comprises a cryptographic card.

11. 1. A computer system for facilitating processing within a computing environment, the system comprising: Memory and at least one processor in communication with the memory, the computer system configured to perform a method, the method comprising: and dynamically determining, by the auxiliary processor, whether a command obtained by the auxiliary processor should be processed by the auxiliary processor, the dynamically determining being performed on a command-by-command basis, the dynamically determining comprising: obtaining, by the auxiliary processor, a command request of a requestor, the command request including at least one filtering indicator indicating at least one valid command type for processing by the auxiliary processor for the requestor, the at least one valid command type including each requestor's allowable command type to be processed for the requestor based on the requestor's computing policy; determining, by the auxiliary processor using the at least one filtering indicator, whether a command in the command request is valid for processing by the auxiliary processor for the requestor; processing the command by the auxiliary processor based on a determination that the command is valid for processing by the auxiliary processor for the requestor; said dynamically determining including: at least one processor including A computer system comprising:

12. 1. A computer-implemented method for facilitating processing within a computing environment, the computer-implemented method comprising: and dynamically determining, by the auxiliary processor, whether a command obtained by the auxiliary processor should be processed by the auxiliary processor, the dynamically determining being performed on a command-by-command basis, the dynamically determining comprising: obtaining, by the auxiliary processor, a command request of a requestor, the command request including at least one filtering indicator indicating at least one valid command type for processing by the auxiliary processor for the requestor, the at least one valid command type including each requestor's allowable command type to be processed for the requestor based on the requestor's computing policy; determining, by the auxiliary processor using the at least one filtering indicator, whether a command in the command request is valid for processing by the auxiliary processor for the requestor; processing the command by the auxiliary processor based on a determination that the command is valid for processing by the auxiliary processor for the requestor; said dynamically determining including:

20. A computer-implemented method comprising:

Images