Diagnostic commands to perform certificate verification-related functions

Abstract

An instruction to be executed within the computing environment is obtained. The instruction includes an operation code indicating a diagnostic operation. The instruction is executed. The execution step includes obtaining a token as input to the instruction, and comparing the token with the current token for configuring the computing environment. Based on the token that matches the current token, one or more verification certificates are returned from the certificate store.

Description

Background Art

[0001] One or more aspects generally relate to facilitating processing within a computing environment, and particularly to improving verification certificate processing used during an initial program load within a computing environment.

[0002] In one example of performing an initial program load of software, the software is loaded, for example, into a logical partition. The initial program load is typically a multi-stage process in which, for example, firmware on a machine performs an initial program load of a portion of the software such as a boot loader, and the boot loader in turn loads into a main program (often an operating system), and then the main program typically in turn loads into additional software packages and programs. Verification that the software loaded during the initial program load and thereafter by the software itself is authentic and has not been changed from what was provided by the software signer is typically performed by validating the software using a public key (stored within a certificate such as a verification certificate) corresponding to the private key used by the software signer to sign the software.

[0003] In this situation, the verification keys used both by the firmware (to perform the initial program load) and by the software may be the same or may not be the same. Also, the signer may change the verification key used to sign the software over time to protect the verification key. Thus, the processing associated with the verification process, including the use of verification certificates, will be facilitated.

Summary of the Invention

[0004] The provisioning of computer program products to facilitate processing within a computing environment overcomes the shortcomings of prior art and provides additional advantages. The computer program product comprises one or more computer-readable storage media and program instructions collectively stored in the one or more computer-readable storage media for executing a method. The method has a step of obtaining an instruction to be executed within the computing environment. The instruction includes an operation code indicating a diagnostic operation. The instruction is executed. The execution step has a step of obtaining a token as input to the instruction and a step of comparing the token with a current token for configuring the computing environment. Based on the token that matches the current token, one or more verification certificates are returned from a certificate store.

[0005] Computer implementation methods and systems relating to one or more embodiments are also described and claimed herein. Furthermore, services relating to one or more embodiments may also be described and claimed herein.

[0006] Additional features and advantages are realized through the techniques described herein. Other embodiments and aspects are described in detail herein and are considered to be part of the claimed embodiments. [Brief explanation of the drawing]

[0007] One or more embodiments are specifically identified and claimed separately as examples in the claims at the end of this specification. The purposes, features, and advantages of the foregoing and one or more embodiments are evident from the following detailed description in conjunction with the accompanying drawings. [Figure 1A] This figure shows one example of a computing environment that incorporates and uses one or more aspects of the present invention. [Figure 1B] This figure shows another example of a computing environment that incorporates and uses one or more aspects of the present invention. [Figure 2]This figure shows one example of further details of a processor or processor unit according to one or more embodiments of the present invention. [Figure 3] Figure 3A shows an example of a submodule of the diagnostic processing module, for example, Figure 1A, according to one or more embodiments of the present invention. Figure 3B shows an example of a submodule of the instruction execution submodule of Figure 3A, according to one or more embodiments of the present invention. [Figure 4] Figure 4A shows one example of the format of a diagnostic instruction according to one or more aspects of the present invention. Figures 4B to 4C show one example of the fields of a register pair used by the execution of one example of the diagnostic instruction in Figure 4A according to one or more aspects of the present invention. Figure 4D shows one example of the fields of a register used by the execution of one example of the diagnostic instruction in Figure 4A according to one or more aspects of the present invention. [Figure 5A] This figure shows one example of diagnostic command processing according to one or more aspects of the present invention. [Figure 5B] This figure shows one example of further detail in performing the function shown in Figure 5A, according to one or more embodiments of the present invention. [Figure 5C] This figure shows another example of further detail in performing the function shown in Figure 5A, according to one or more embodiments of the present invention. [Figure 5D] This figure shows another example of further detail in performing the function shown in Figure 5A, according to one or more embodiments of the present invention. [Figure 6] This figure shows one example of a verification certificate storage size block used according to one or more aspects of the present invention. [Figure 7A] This figure shows one example of a verification certificate block used according to one or more aspects of the present invention. [Figure 7B] This figure shows one example of a verification certificate entry in the verification certificate block of Figure 7A, according to one or more embodiments of the present invention. [Figure 8A] This figure shows one example of a verification certificate extraction block used according to one or more aspects of the present invention. [Figure 8B] This figure shows one example of a verification certificate extraction entry in the verification certificate extraction block of Figure 8A, according to one or more embodiments of the present invention. [Figure 8C] This figure shows one example of an elliptic curve verification key block used according to one or more aspects of the present invention. [Figure 9] Figures 9A and 9B show another example of a computing environment incorporating and using one or more aspects of the present invention. [Modes for carrying out the invention]

[0008] According to one or more aspects of the present invention, the ability to facilitate processing within a computing environment is provided. In one aspect, this ability includes, for example, facilitating processing related to verification certificates used in the initial program loading of a program (e.g., a boot loader, an operating system, etc.). In one example, this ability includes using an instruction (e.g., a single designed instruction) configured to perform one or more functions related to a certificate store facility that stores verification certificates.

[0009] In one or more embodiments, an instruction is configured to include multiple subcodes for multiple functions, and a particular subcode is selected for a particular execution of the instruction. One or more actions are performed in a particular execution of the instruction based on the selected subcode. Instructions may be issued by a program, including, but not limited to, a bootloader, an operating system, etc. In other embodiments, other programs, entities, and / or components may issue instructions. Many options and / or modifications are possible.

[0010] In one or more embodiments, instructions are referred to herein as diagnostic instructions, and processes associated with instructions, including processes associated with verification certificates, are referred to herein as diagnostic processes. Instructions may be used by other programs and / or entities and / or for other purposes. Many modifications and options are possible.

[0011] One or more aspects of the present invention are incorporated into a computing environment and executed and / or used by such computing environment. For example, the computing environment may be of various architectures and types, but is not limited to, personal computing, client-server, distributed, virtual, emulated, partitioned, unpartitioned, cloud-based, quantum, grid, time-sharing, cluster, peer-to-peer, wearable, mobile, having one or more nodes, having one or more processors, and / or any other type of environment and / or configuration capable of executing, for example, diagnostic processing (including the execution of selected subcodes of diagnostic instructions) and / or processes (or processes) that perform one or more other aspects of the present invention. The aspects of the present invention are not limited to any particular architecture or environment.

[0012] Various aspects of this disclosure are described by explanatory text, flowcharts, block diagrams of computer systems and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flowchart, operations may be performed in a different order than those shown in a given flowchart, depending on the technology involved. For example, again, depending on the technology involved, two operations shown in consecutive flowchart blocks may be performed in reverse order, as a single integrated stage, simultaneously, or with at least partial time overlap.

[0013] Computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media ("mediums") that collectively comprise a set of one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP claim. A "storage device" is any tangible device capable of holding and storing instructions for use by a computer processor. Computer-readable storage media may be, but are not limited to, electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, mechanical storage media, or any suitable combination of those described above. Some known types of storage devices, including these media, include 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), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices (such as pits / lands formed on the main surface of a punch card or disk), or any suitable combination of the foregoing. When the term "computer-readable storage medium" is used in this disclosure, it shall not be interpreted as storage in the form of a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses passing through optical fiber cables, electrical signals communicated through wires, and / or other transmission media.As those skilled in the art will understand, data is typically moved at several intermittent points during the normal operation of a storage device, such as during access, defragmentation, or garbage collection; however, data is not transient while it is stored, and therefore, a storage device is not transient.

[0014] One example of a computing environment that implements, incorporates, and / or uses one or more aspects of the present invention is described with reference to Figure 1A. In one example, the computing environment 100 includes an example of an environment for executing at least a portion of computer code involved in executing the methods of the present invention, such as diagnostic processing code or module 150. In addition to block 150, the computing environment 100 includes, for example, a computer 101, a wide area network (WAN) 102, an end user device (EUD) 103, a remote server 104, a public cloud 105, and a private cloud 106. In this embodiment, the computer 101 includes a processor set 110 (including processing circuits 120 and a cache 121), a communication fabric 111, volatile memory 112, persistent storage 113 (including an operating system 122 and blocks 150 as identified above), a peripheral device set 114 (including a user interface (UI) device set 123, storage 124, and an Internet of Things (IoT) sensor set 125), and a network module 115. The remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a host physical machine set 142, a virtual machine set 143, and a container set 144.

[0015] Computer 101 may take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device known currently or developed in the future that is capable of executing programs, accessing a network, or querying a database such as remote database 130. As is well understood in the technical field of computer technology and depending on the technology, the execution of computer implementation methods may be distributed among multiple computers and / or across multiple locations. On the other hand, in this presentation regarding computing environment 100, for the sake of keeping the presentation as concise as possible, the detailed discussion focuses on a single computer, specifically computer 101. Although not shown in the cloud of FIG. 1A, computer 101 may be located in the cloud. On the other hand, computer 101 is not required to exist within the cloud except for any range that may be affirmatively shown.

[0016] Processor set 110 includes one or more computer processors of any type known currently or developed in the future. Processing circuit 120 may be distributed across multiple packages, e.g., multiple coordinated integrated circuit chips. Processing circuit 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on processor set 110. Cache memory is typically organized into multiple levels depending on its relative proximity to the processing circuit. Alternatively, some or all of the cache for the processor set may be located "off-chip". In some computing environments, processor set 110 may be designed to function using qubits and perform quantum computing.

[0017] Computer-readable program instructions typically cause a series of operational steps to be performed by a processor set 110 of computer 101, thereby implementing a computer-implemented method by being loaded onto computer 101, whereby the instructions so executed instantiate the method specified in the flowchart and / or description of the computer-implemented method (collectively referred to as "the method of the present invention") included in this written description. These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by processor set 110 to control and direct the execution of the method of the present invention. In computing environment 100, at least some of the instructions for performing the method of the present invention may be stored in block 150 within persistent storage 113.

[0018] Communication fabric 111 is a signal conduction path that enables various components of computer 101 to communicate with each other. Typically, this fabric is made up of switches and conductive paths, such as buses, bridges, physical input / output ports, and switches and conductive paths that make up the same, etc. Other types of signal communication paths, such as optical fiber communication paths and / or wireless communication paths, may be used.

[0019] Volatile memory 112 is any type of volatile memory known currently or developed in the future. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, volatile memory is characterized by random access, although this is not required unless affirmatively indicated. In computer 101, volatile memory 112 is located within a single package and exists inside computer 101. Alternatively or in addition, volatile memory may be distributed across multiple packages and / or located externally to computer 101.

[0020] The persistent storage 113 is any form of non-volatile storage for a computer, currently known or to be developed in the future. The non-volatility of this storage means that the stored data is maintained whether or not power is directly supplied to the computer 101 and / or the persistent storage 113. The persistent storage 113 may be read-only memory (ROM), but typically at least a portion of the persistent storage allows for writing, deleting, and rewriting of data. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. The operating system 122 may take several forms, such as various known proprietary operating systems or open-source portable operating system interface (CSI) type operating systems employing a kernel. The code contained in block 150 typically includes at least a portion of computer code involved in performing the method of the present invention.

[0021] The peripheral device set 114 includes a set of peripheral devices of the computer 101. Data communication connections between the peripheral devices of the computer 101 and other components may be implemented in various ways, such as Bluetooth connections, near-field communication (NFC) connections, connections made by cables (such as universal serial bus (USB) type cables), insert-type connections (e.g., secure digital (SD) cards), connections made via local area communication networks, and even connections made via wide area networks such as the internet. In various embodiments, the UI device set 123 may include components such as a display screen, speaker, microphone, wearable devices (such as goggles and smartwatches), keyboard, mouse, printer, touchpad, game controller, and haptic device. Storage 124 is external storage such as an external hard drive, or insertable storage such as an SD card. Storage 124 may be persistent and / or volatile. In some embodiments, storage 124 may take the form of a quantum computing memory device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (for example, computer 101 locally stores and manages a large database), this storage may be provided by peripheral storage devices designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 125 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another may be a motion detector.

[0022] The network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers via the WAN 102. The network module 115 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for transmission over a communication network, and / or web browser software for communicating data over the internet. In some embodiments, the network control and network forwarding functions of the network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN)), the control and forwarding functions of the network module 115 are performed on physically separate devices, such that the control function manages several different network hardware devices. Computer-readable program instructions for performing the method of the present invention can typically be downloaded from an external computer or external storage device to computer 101 through a network adapter card or network interface included in the network module 115.

[0023] WAN102 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances by any currently known or future-developed technology for transmitting computer data. In some embodiments, WAN102 may be replaced and / or supplemented by a local area network (LAN), such as a Wi-Fi network, designed to transmit data between devices located in a local area. WANs and / or LANs typically include computer hardware such as copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0024] The end-user device (EUD) 103 is any computer system used and controlled by an end-user (e.g., a customer of the company operating computer 101) and can take any of the forms discussed above in relation to computer 101. Typically, EUD 103 receives useful and valuable data from the operation of computer 101. For example, in a hypothetical case where computer 101 is designed to provide recommendations to the end-user, these recommendations would typically be communicated from the network module 115 of computer 101 to EUD 103 via WAN 102. In this way, EUD 103 can display or otherwise present the recommendations to the end-user. In some embodiments, EUD 103 may be a client device such as a thin client, heavy client, mainframe computer, or desktop computer.

[0025] The remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. The remote server 104 may be controlled and used by the same entity that operates computer 101. The remote server 104 represents a machine that collects and stores useful and valuable data for use by other computers, such as computer 101. For example, in the hypothetical case where computer 101 is designed and programmed to provide recommendations based on historical data, this historical data may be provided to computer 101 from the remote database 130 of the remote server 104.

[0026] The public cloud 105 is any computer system available for use by multiple entities, providing on-demand availability of computer system resources and / or other computing capabilities, particularly data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct active management of the computing resources of the public cloud 105 is performed by the computer hardware and / or software of the cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers that make up the host physical machine set 142, which is the universe of physical computers available in and / or to the public cloud 105. The virtual computing environment (VCE) typically takes the form of virtual machines from the virtual machine set 143 and / or containers from the container set 144. These VCEs may be stored as images and are understood to be transferable either as images or after instantiation of the VCE, among and between various physical machine hosts. The cloud orchestration module 141 manages the transfer and storage of images, deploys new VCE instances, and manages active instances of the VCE deployment. The gateway 140 is a collection of computer software, hardware, and firmware that enables the public cloud 105 to communicate over the WAN 102.

[0027] Here, some further explanation of virtualized computing environments (VCEs) is provided. A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from an image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature in which the kernel allows for the existence of multiple isolated user-space instances called containers. These isolated user-space instances typically behave as actual computers from the perspective of the programs running in them. Computer programs running on a normal operating system can utilize all of that computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and the devices allocated to the container; this feature is known as containerization.

[0028] The private cloud 106 is similar to the public cloud 105, except that its computing resources are available only for use by a single enterprise. While the private cloud 106 is shown as communicating with the WAN 102, in other embodiments, the private cloud may be completely isolated from the internet and accessible only via a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. Each of the multiple clouds remains a separate discrete entity, but the larger hybrid cloud architecture is coupled by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple configuration clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud.

[0029] The computing environment described above is merely one example of a computing environment that incorporates, runs, and / or uses one or more aspects of the present invention. Other examples are possible. For example, in one or more embodiments, one or more of the components / modules in Figure 1A are not included in the computing environment and / or are not used for one or more aspects of the present invention. Furthermore, in one or more embodiments, additional and / or other components / modules may be used. Other modifications are possible.

[0030] Another example of a computing environment that incorporates, uses, and / or runs one or more aspects of the present invention is described with reference to Figure 1B. In one example, the computing environment 160 includes, for example, memory 165 (known as system memory, main memory, main storage, central storage, storage; for example, persistent storage, for example persistent storage 113; other storage; etc.) which supports logical partitioning and is coupled to one or more processor units 190 (for example, a central processing unit: CPU, other types of processors, etc.) of a processor set (for example, a processor set 110).

[0031] Memory 165 includes, for example, one or more logical partitions 170, a logical partition manager, such as a hypervisor 172, firmware 174, and, according to one or more aspects of the present invention, a certificate store 185 (further described below). One example of the hypervisor 172 is the IBM® PR / SM® (Processor Resource / System Manager) logical partition manager offered by International Business Machines Corporation, located in Armonk, New York. IBM and PR / SM are trademarks or registered trademarks of International Business Machines Corporation in at least one jurisdiction. Other hypervisors and / or managers may be used in other examples.

[0032] Logical partitioning support provides the ability to operate multiple logical partitions 170, each capable of running a different program 180 and a guest operating system 182. Each logical partition 170 can function as a separate system; that is, each logical partition can be independently reconfigured, run a guest operating system, and operate with different programs. An operating system or application program running on a logical partition appears to have access to a full and complete system, but in reality, only a portion of it is available.

[0033] In one example, a logical partition 170 contains one or more logical processors, each of which represents all or a percentage of the physical processor resources (e.g., processor units 190) that can be dynamically allocated to the logical partition.

[0034] Firmware 174 includes, for example, processor and / or system microcode. It includes, for example, data structures used in the implementation of hardware-level instructions and / or higher-level machine code. In one embodiment, it typically includes, for example, proprietary code that is delivered as microcode containing trusted software or microcode specific to the underlying hardware and controls operating system access to system hardware.

[0035] In one example, firmware 174 includes a bootloader 176 used in the initial program loading (IPL) of a selected program, such as an operating system. Initial program loading provides a mechanism for causing a program (e.g., a bootloader, an operating system) to be read from a specified device and for initiating the execution of that program. In one or more embodiments, bootloader code (also referred to as the bootloader, e.g., bootloader 176) is loaded, copied, or otherwise present in the firmware and used when performing the initial program loading of a program (e.g., an operating system). One particular type of initial program loading is a list-oriented initial program loading, which allows the program (e.g., an operating system) to be loaded from various types of input / output devices.

[0036] A program loaded by initial program loading or otherwise started executes instructions that perform actions within the computing environment. To execute instructions, one example uses, for example, a functional component of a processor unit or processor (e.g., a processor set 110). One example of a functional component used to execute instructions is illustrated with reference to Figure 2. In one example, the functional component used to execute instructions includes, for example, an instruction fetch component 200 that fetches the instructions to be executed; an instruction decode / operand fetch component 202 that decodes the fetched instructions and retrieves the operands of the decoded instructions; one or more instruction execution components 204 that execute the decoded instructions; a memory access component 206 that accesses memory for instruction execution if necessary; and a writeback component 208 that provides the results of the executed instructions. One or more of the components may access and / or use one or more registers 210 in instruction processing. Furthermore, one or more of the components may access and / or use a diagnostic processing module 150. In one or more embodiments of the present invention, additional, fewer, and / or other components may be used.

[0037] A diagnostic processing module (e.g., diagnostic processing module 150) includes code or instructions used to perform a diagnostic process according to one or more aspects of the present invention. In one example, the diagnostic processing module (e.g., diagnostic processing module 150) includes various submodules used to perform the process. The submodules are, for example, computer-readable program code (e.g., instructions) in a computer-readable medium, e.g., storage (e.g., storage 124, persistent storage 113, cache 121, other storage). The computer-readable medium may be part of a computer program product, and the computer-readable program code may be executed by and / or using one or more computing devices (e.g., one or more computers, e.g., computer 101; one or more servers, e.g., remote server 104; one or more processors, e.g., processor units or processors of processor set 110; processing circuits, e.g., processing circuit 120 of processor set 110; and / or other computing devices, etc.). Additional, fewer, and / or other computers, servers, processors, processor units, processing circuits, and / or computing devices may be used to run one or more of the submodules and / or parts thereof. Many examples are possible.

[0038] One example of the diagnostic processing module 150 is described with reference to Figure 3A. In this example, the diagnostic processing module 150 includes an instruction acquisition submodule 300 that acquires (e.g., receive, provide, pull, retrieve, fetch, issue, etc.) diagnostic instructions to be executed, and an instruction execution submodule 310 used to execute the diagnostic instructions.

[0039] In one example, referring to Figure 3B, the instruction execution submodule 310 includes, for example, an operand acquisition submodule 312 that acquires one or more operands of a diagnostic instruction; a function determination submodule 314 that determines the function to be performed by the diagnostic instruction; and a function execution submodule 316 that performs the determined function. Additional, fewer, and / or other submodules may be used to implement diagnostic processing, including the execution of the diagnostic instruction and / or other processing associated therewith.

[0040] One example of a diagnostic instruction is illustrated with reference to Figure 4A. In one embodiment, a diagnostic instruction, for example, diagnostic instruction 400 (also referred to as diagnostic "0320" in one particular architecture), is a single designed hardware machine instruction in the hardware / software interface. It is configured to include multiple subcodes, the particular subcode being indicated in the instruction call. The execution of each subcode involves performing one or more actions as part of the execution of the diagnostic instruction that specifies the subcode.

[0041] As an example, diagnostic instructions are part of an instruction set architecture in one implementation. One example of an instruction set architecture and / or aspects of the present invention that incorporates and / or uses diagnostic instructions is the IBM® z / Architecture® instruction set architecture offered by International Business Machines Corporation, located in Armonk, New York. One embodiment of the z / Architecture instruction set architecture is described in the publication entitled “z / Architecture Principles of Operation,” IBM Publication No. SA22-7832-12, Thirteenth Edition, September 2019, which is thereby incorporated herein by reference in its entirety. However, the z / Architecture instruction set architecture is merely an illustrative architecture; other architectures and / or other types of computing environments of International Business Machines Corporation and / or other entities / companies may include and / or use one or more aspects of the present invention. z / Architecture is a trademark or registered trademark of International Business Machines Corporation in at least one jurisdiction.

[0042] In one example, a diagnostic instruction 400 has a format referred to as a register and storage operand format, which has, for example, 32 bits. In this particular example, the diagnostic instruction 400 has an operation code (e.g., opcode) field 402 (e.g., bits 0-7) that specifies the diagnostic operation; a register (e.g., R1) field 404 (e.g., bits 8-11) that specifies at least one general-purpose register to be used in the execution of the diagnostic instruction; another register (e.g., R3) field 406 (e.g., bits 12-15) that specifies at least one general-purpose register to be used in the execution of the diagnostic instruction; a base register field (e.g., B2) 408 (e.g., bits 16-19) that specifies the base register; and a displacement (e.g., D2) field 410 (e.g., bits 20-31) that specifies a displacement value to be added to the value in the base register specified in the base register field 408 in order to provide a value that will be used as an operation code extension for the diagnostic instruction 400. Each of the fields is described below.

[0043] In one example of diagnostic instruction 400, the contents of field D2 410 are added to the contents of the general-purpose register specified in field B2 408. The result is not used to address data; instead, selected bits (e.g., bits 0-47) are ignored, and other selected bits (e.g., bits 48-63) are used as an operation code extension. If the operation code extension is a selected operation code (e.g., "0320" hex), one or more certificate store functions are performed.

[0044] In one embodiment, the R1 field 404 specifies the even register of an even-odd pair of general-purpose registers; otherwise, in one example, a specification exception is recognized. The R1+1 field specifies the odd register of an even-odd pair. In one example, referring to Figure 4B, the content 404a of general-purpose register R1 specifies, for example, the first operand address 420. For example, general-purpose register R1 specifies a logical address in storage where specified certificate store (CS) functional information for the current configuration (e.g., for guests, e.g., guest operating system (e.g., guest operating system 182) and / or other guests) will be stored. The logical address is generated under the control of the current addressing mode. In one example, in access-register mode, access register R1 specifies the address space where the response block will be stored. Other examples are possible. The location at the specified logical address will be accessible throughout the execution of the diagnostic instruction. When dynamic address translation (DAT) is enabled, address translation may be performed on one 4K byte page (or other selected size) at a time, and the resulting frame may be accessed without interlocking with DAT serialization operations on other processors (such as invalid page table entries). If an access exception occurs during storage to any part of the response buffer, the contents of any accessible part of the response buffer are unpredictable, even if the exception is defined to suppress or cancel instruction execution.

[0045] In one example, prior to calling diagnostic "0320," the operating system may "pin" the storage area addressed by the contents of general-purpose register R1 to prevent the translation from being invalidated by memory management on another processor. In one example, if virtual addressing is used, the diagnostic "0320" instruction performs dynamic address translation prior to accessing the page, but the subsequent store to that page is not interlocked with invalid page table entries from other processors. Therefore, the diagnostic instruction can continue storing to that page frame even after memory management on another processor has reallocated it.

[0046] In one example, referring to Figure 4C, for instance, response code 422 is returned at bit positions 48-63 of content 404b of general-purpose register R1+1. For example, a response code of 0001hex indicates that the operation was successful, and a response code of 0102hex indicates that the subcode is not supported on this model. Other response codes / response code values ​​are possible.

[0047] Furthermore, in one example, referring to Figure 4D, the contents 406a of general-purpose register R3 (e.g., bits 56-63) include a subcode 432 (e.g., an 8-bit unsigned integer) that determines a specific function to be performed by a diagnostic instruction. The example subcodes include, for example, subcode 0—queries the installed subcodes that will be used to determine the subcodes supported by diagnostic "0320"; subcode 1—queries the verification certificate storage information; subcode 2—stores the verification certificate; and subcode 3—stores the verification certificate extraction. Additional, fewer, and / or other subcodes may be provided.

[0048] In one embodiment, the fields of an instruction are distinct and independent of each other; however, in other embodiments, more than one field may be combined. Furthermore, a field may be extended to more than one location. For example, a field may be in one set of bits and extended to another set of bits distinct from that one set of bits (e.g., at the beginning of the instruction format and at the end of the instruction format; and / or variations thereof). While exemplary types of registers are specified, other types of registers may be used. Moreover, while exemplary locations are provided in the instruction format, other locations may be used for one or more of the instruction fields. Diagnostic instructions, e.g., diagnostic instruction 400, may have additional, fewer, and / or other fields. Other examples are possible.

[0049] Furthermore, in the description herein of a diagnostic instruction, for example, diagnostic instruction 400, a specific location of a field, a specific field, and / or a specific size (e.g., a specific byte and / or bit) may be indicated. However, other locations, fields, and / or sizes may be provided. Furthermore, a specific value of a bit, for example, setting it to 1 or zero, may be specified, but this is merely an example. In other examples, a bit may be set to a different value, such as the opposite value, or to another value, if set. Many variations are possible.

[0050] If a subscript is associated with a field, the subscript associated with the field indicates the operand to which the field belongs. For example, the subscript 1 associated with register R1 indicates that the register specified using R1 contains the first operand, the subscript 2 associated with base registers B2 and D2 indicates the second operand, and so on.

[0051] In one example, a diagnostic instruction (e.g., diagnostic instruction 400 with a selected behavior code extension (e.g., "0320" hex)) provides various functions associated with the Certificate Store (CS) facility. For example, it retrieves the current validated certificate information from the certificate store (e.g., certificate store 185) for the requested configuration (e.g., for a guest, e.g., a guest operating system (e.g., guest operating system 182) and / or for other guests) and returns the certificate information to the program. Validated certificates are validated before being placed in the certificate store.

[0052] In one example, a certificate store (e.g., certificate store 185) used to dynamically manage certificates (e.g., verification certificates) manages certificates for one or more configurations (e.g., guests) at a particular guest or configuration level. For example, there may be multiple levels of guests, e.g., one level of guests running under one level of hypervisor (e.g., a logical partition hypervisor (e.g., hypervisor 172)), and another level of guests running under another level of hypervisor (e.g., the IBM® z / VM® hypervisor or another hypervisor offered by International Business Machines Corporation and / or other companies / entities. z / VM is a trademark or registered trademark of International Business Machines Corporation in at least one jurisdiction. In other examples, other hypervisors and / or managers may be used). In this example, the same certificate store is used for each configuration level. That is, in one example, each configuration level has its own machine (e.g., central electronic complex) certificate store. In other examples, it is common for multiple configuration levels. In another example, each configuration (or subset of configurations) has its own certificate store. In yet another example, each hypervisor has its own certificate store. Other variations are possible.

[0053] In one or more ways, new certificates can be added to the certificate store, and old certificates can be dynamically removed from the certificate store at any time. In one example, each time a certificate is added or removed, the certificate store token is updated with a new unique value. If a counter is used, the counter is incremented even when a certificate is removed (it is not a count of certificates currently in the certificate store in this example). If no counter is used, a new unique value will be used until the entire set of possible values ​​is used to prevent a user from encountering duplicate values ​​for two or more versions of the same certificate store for their configuration. If there are more than one logical system (e.g., configuration levels), each certificate store per logical system will adhere to these rules. As a result, each certificate store may use its own certificate store token value generation scheme. Thus, each certificate store may return a different certificate store token value for each configuration at any given point in time. Other modifications are possible.

[0054] In one example, verification certificates for a given configuration are stored in verification certificate blocks (VCBs). These are indexed from 1 to N in one example. However, not all verification certificates in an indexed list necessarily contain valid certificates (i.e., there may be indexed entries that are not marked as valid).

[0055] In one example, the certificate store also maintains specific materials extracted from verification certificates for certain key types, such as elliptic curve keys. The set of extracted key type materials for a verification certificate is called a verification certificate extract (VCX). In one example, verification certificate extracts are stored separately in a verification certificate extract block (VCXB). (In other examples, they may be stored together with the verification certificate; various possibilities exist.) For a given configuration, verification certificate extracts are indexed from 1 to N in one example; for a given configuration, the index of a verification certificate extract is the same as the index of the verification certificate from which the specific material is extracted. That is, VCX X , VC X This corresponds to the above. However, not all validation certificate extractions in an indexed list can store a valid validation key (i.e., there may be indexed entries that do not store a valid validation key).

[0056] In one example, the verification certificates and verification certificate extracts maintained in the certificate store are retrieved and stored, for example, by executing a command, such as diagnostic "320". Deleted or expired verification certificates are indicated as invalid verification certificates in their respective control block entries. In one example, if a verification certificate is invalid, its corresponding verification certificate extract is also invalid.

[0057] If a verification certificate is valid and the verification certificate extraction format contains a key of a supported key type, then the corresponding verification certificate extraction is also valid. Therefore, a valid verification certificate does not necessarily imply a valid verification certificate extraction.

[0058] In one example, the Certificate Store (CS) token value is used to represent the current version of the list of validation certificates and their corresponding validation certificate extracts that are available in the certificate store for its configuration (e.g., for guests, e.g., guest operating system (e.g., guest operating system 182) and / or other guests). The value in this field changes when changes occur in the certificate store for its configuration. For example, this value is updated each time one or more validation certificates and their corresponding validation certificate extracts are added, removed, or modified.

[0059] In one example, the certificate store token value is not updated while the certificate store function is running. In another example, the list of validated certificates and the corresponding list of validated certificate extracts are not added to, removed from, or modified in the certificate store for their configuration until the currently running diagnostic "0320" function has finished executing. Similarly, while the validated certificates and their corresponding validated certificate extracts are being updated for their configuration, subsequent diagnostic "0320" functions are not started.

[0060] In one example, certificate store token values ​​are not reused until each certificate store token value has been used. Other variations are possible.

[0061] Furthermore, in one example, a program (e.g., a bootloader, operating system) ensures that if it discovers that the certificate store token value has changed due to its configuration, the relevant information retrieved from the certificate store for any pre-configuration will be re-evaluated. This includes the maximum and largest values ​​described herein. Moreover, in one example, indexing for the certificate store has a single origin. A request containing a certificate with a zero index provides an indication that no certificates are available for that index.

[0062] As shown, in one embodiment, a diagnostic command implements several subcodes, three of which are described herein in accordance with one or more aspects of the present invention. These subcodes are referred to, for example, as subcode 1—queries verification certificate storage information; subcode 2—stores verification certificates; and subcode 3—stores verification certificate extractions; however, they may be referred to in other ways. Each of the subcodes is described further below.

[0063] Subcode 1 - Verification Certificate Storage Information Query

[0064] In one or more embodiments, a program (e.g., a boot loader, an operating system, or another program) may use diagnostic subcode 1 "0320" to obtain certificate store information in order to discover the current version number of the certificate store for the current configuration, and to determine the amount of storage that will be used to store one or more verification certificates (VCs) and / or their corresponding verification certificate extracts (VCXs) from the certificate store for the current configuration.

[0065] In one embodiment, subcode 1 returns various storage sizes specific to, for example, the Certificate Validation Block (VCB) and the Certificate Extraction Block (VCXB).

[0066] If a verification certificate does not exist for that configuration, the verification certificate storage size block (VCSSB) length is set to a defined value, for example, 4, and a response code 422, for example 0001hex, is returned, for example, at bit positions 48-63 of general-purpose register R1+1.

[0067] In one example, diagnostic "0320" subcode 1 is valid when the Certificate Store (CS) facility is installed on one specific architecture and architecture mode (e.g., the z / Architecture instruction set architecture in architecture mode). This check does not need to be performed for other architectures, and / or other architectures may perform other checks. Many possibilities exist.

[0068] In one example, the first operand is specified on a double word boundary; otherwise, in one example, a specification exception is recognized. Furthermore, in one example, the output data returned by diagnostic subcode 1 when the operation completes successfully is stored, for example, in a Verification Certificate Storage Size Block (VCSSB), an example of which is described below.

[0069] During operation, in one example, subcode 1 (i.e., execution of diagnostic instruction 400 having subcode 432 set to 1) retrieves certificate store information to discover the current version number of the certificate store for the current configuration and to determine the amount of storage that will be used to store one or more validation certificates and / or their corresponding validation certificate extracts from the certificate store for the current configuration.

[0070] In one example, this involves obtaining a consistent set of information about how many verification certificates and / or verification certificate extracts will be provided by the subsequent issuance of diagnostic "0320" instructions, along with the storage requirements for retrieving these certificate materials, either all at once or incrementally, one or more at a time (to conserve memory requirements).

[0071] The diagnostic "0320" subcode 1 returns information to satisfy different operating system implementations by, for example, providing the maximum singleton verifier certificate block / verifier extract block length, which determines the minimum number of bytes in the data unit that will be used to retrieve the verifier certificate block / verifier extract block, for example, by providing at least one verifier certificate block / verifier extract block entry currently available in the certificate store for the current configuration; providing all verifier certificate block / verifier extract block entries currently available in the certificate store for the current configuration, for example, by providing the total verifier certificate block / verifier extract block length for the current configuration, which determines the minimum number of bytes that will be used to retrieve the verifier certificate block / verifier extract block; and / or providing the number of bytes that will be used to store the maximum number of verifier certificate entries / verifier extract entries supported by the current machine model on which the software is running. For example, the maximum number of verifier certificate entries / verifier extract entries supported by the current model of the central electronic complex (CEC) containing the logical partition on which the software is running is provided.

[0072] In one or more embodiments, the hypervisor ensures that a program does not encounter updated results while it is collecting the certificate list and / or certificate extract list for the current configuration across multiple instances of issuing the diagnostic "0320" instruction. The operating system does not need to check for consistency in the information returned across these multiple issuances, for example; any information returned successfully will contain a consistent set of information.

[0073] According to one or more aspects of the present invention, a diagnostic process, including the execution of a diagnostic instruction, e.g., a diagnostic instruction 400, is performed using a diagnostic process. Examples of such processes are illustrated with reference to Figures 5A to 5D. In one example, the diagnostic process (e.g., diagnostic process 500) may be implemented using one or more submodules (e.g., one or more of submodules 300 to 316) and executed by one or more computing devices (e.g., one or more computers (e.g., computer 101, other computers, etc.), one or more servers (e.g., server 104, other servers, etc.), one or more processors, processor units, nodes and / or processing circuits, etc. (e.g., processor set 110 or other processor sets), and / or other computing devices, etc.). While exemplary computing devices, computers, servers, processors, processor units, nodes and / or processing circuits are provided, additional, fewer and / or other computers, servers, processors, processor units, nodes, processing circuits and / or computing devices may be used for the diagnostic process and / or other processes. There are various options available.

[0074] Referring to Figure 5A, in one example, the diagnostic process 500 obtains (502) instructions, such as diagnostic instructions 400 (502) (e.g., receive, retrieve, fetch, provide, pull, issue, etc.). For example, in one example, a program (e.g., a boot loader or operating system) issues a diagnostic "0320" instruction specifying subcode 1 (validation certificate storage information query) to obtain specific storage information for the current configuration in order to determine the amount of storage that will be used to store one or more validation certificates and / or their corresponding validation certificate extracts in the certificate store for the current configuration. These data blocks are used, for example, to validate signed load modules (binary code). Based on the issuance of instructions by the program, process 500 obtains the instructions and executes (510) the instructions, for example, via a hypervisor (e.g., hypervisor 172). Execution includes, for example, obtaining one or more operands of the instructions 512. For example, process 500 obtains one or more of the following: an operation code using the opcode field 402, a subcode 432 using the R3 field 406, and a first operand address 420 using the R1 field 404. In one or more embodiments, additional, fewer, and / or other operands may be used. Many modifications are possible.

[0075] Based on obtaining the operand, in one example, process 500 determines the function to be executed (for example, as specified by subcode 432) (514). In one example, the function is the Verification Certificate Storage Information Query function specified by subcode 1. However, additional, fewer, and / or other functions may be specified. Furthermore, in other embodiments, no subcode is specified, and instead, the function is determined from another field of the instruction, for example, one or more opcode fields, one or more other fields; or it is implied, etc. Many variations are possible.

[0076] In one example, based on determining a function, process 500 executes the function (516). For example, a hypervisor (e.g., hypervisor 172) executes a function that includes one or more actions of the function. In other examples, other entities, components, etc., may execute one or more of the functions and / or one or more actions of a certain function. Many variations are possible.

[0077] Further details regarding one example of performing a function (e.g., a verification certificate storage information query - subcode 1) are illustrated with reference to Figure 5B.

[0078] In one embodiment, process 516a executes a query to obtain storage information which will be used to determine the amount of storage which will be used to store one or more verification certificates and / or their corresponding verification certificate extracts. Process 516a determines, for example, whether any verification certificates exist in the certificate store for the requested configuration (520). If one or more verification certificates exist in the certificate store for the requested configuration, a determination 522 is made of storage size information which will be provided which will be used to determine the amount of storage which will be used to store the selected verification certificates and / or their corresponding extracts.

[0079] Based on the determination of the storage size information to be provided, process 516a stores various storage size information in an information or control block, such as a verification certificate storage size block, an example of which is illustrated with reference to Figure 6. For example, the number of verification certificates available in the certificate store for its configuration, the maximum number of bytes of possible verification certificate entries that can be stored in the certificate store for its configuration, and the maximum number of bytes of possible verification certificate extraction entries that can be stored in the certificate store for its configuration are provided. Additional, less, and / or other storage size information may be provided.

[0080] An example of a Validation Certificate Storage Size Block is illustrated with reference to Figure 6. In this example, Validation Certificate Storage Size Block (VCSSB) 600 includes:

[0081] Verification Certificate Storage Size Block Length 602: This field (e.g., word 0) contains an unsigned binary integer (e.g., 32 bits) specifying the number of bytes in the verification certificate storage size block 600. In one example, this field is set by the program to a minimum of, for example, 128; otherwise, a response code 422 of, for example, 0202hex is returned, for example, at bit positions 48-63 of general-purpose register R1+1. If no verification certificate exists for its configuration, the verification certificate storage size block length is set by the machine (e.g., hypervisor) to a defined value, for example, 4, and a response code 422 of, for example, 0001hex is returned, for example, at bit positions 48-63 of general-purpose register R1+1. Other response codes / response code values ​​may be returned.

[0082] Version 604: This field (e.g., byte 3 of word 1) contains an unsigned binary integer (e.g., 8 bits) that specifies the version number for, for example, the verification certificate storage size block. This field is set to zero, for example.

[0083] Certificate Store (CS) Token 606: This field (e.g., word 4) contains an unsigned binary integer (e.g., 32 bits) that specifies the current version of the certificate store for its configuration (e.g., for guests, e.g., guest operating system (e.g., guest operating system 182) and / or other guests). In one example, the hypervisor obtains this information from a count associated with the certificate store for its configuration (e.g., the current token).

[0084] In one or more embodiments, the same (common) certificate store version (e.g., certificate store token) is used for a particular configuration (e.g., guest) at a specific configuration level (e.g., guest). Therefore, in one example, each hypervisor uses its own certificate store version (CS) token value, and thus one level of hypervisor may have a different certificate store token value than another level of hypervisor. In other examples, they may have the same token value, and / or each configuration may have its own token value. Other modifications are possible.

[0085] Total Validation Certificate Count 608: This field (e.g., bytes 0-1 of word 8) contains an unsigned binary integer (e.g., 16 bits) that specifies the count of Validation Certificates available in the certificate store for its configuration. The count, in one example, includes the index of available Validation Certificates, regardless of the validity status of the stored Validation Certificates.

[0086] Maximum Validated Certificate Count 610: This field (e.g., byte 2-3 of word 8) contains an unsigned binary integer (e.g., 16 bits) that specifies the maximum number of validated certificates that may be stored in the certificate store for their configuration.

[0087] Maximum Validation Certificate Entry Length 612: This field (e.g., word 16) contains an unsigned binary integer (e.g., 32 bits) that specifies the maximum number of bytes of a possible Validation Certificate Entry (VCE) that can be stored in the certificate store for its configuration.

[0088] Maximum Validated Certificate Extraction Entry Length 614: This field (e.g., word 17) contains an unsigned binary integer (e.g., 32 bits) that specifies the maximum number of bytes of a Validated Certificate Extraction Entry (VCXE) that can be stored in the certificate store for its configuration.

[0089] Maximum singleton verifier certificate block length 616: This field (e.g., word 20) contains an unsigned binary integer (e.g., 32 bits) specifying the number of bytes in a verifier certificate block that has the maximum single verifier certificate entry currently available in the certificate store for its configuration.

[0090] Total Validation Certificate Block Length 618: This field (e.g., word 21) contains an unsigned binary integer (e.g., 32 bits) that specifies the total number of bytes used to store a validation certificate block that has validation certificate block entries currently available in the certificate store for its configuration.

[0091] Maximum Singleton Validation Certificate Extract Block Length 620: This field (e.g., word 22) contains an unsigned binary integer (e.g., 32 bits) specifying the number of bytes in a validation certificate extract block that has the maximum single validation certificate extract entry currently available in the certificate store for its configuration.

[0092] Total Validation Certificate Extract Block Length 622: This field (e.g., word 23) contains an unsigned binary integer (e.g., 32 bits) that specifies the total number of bytes in the validation certificate extract block that has the validation certificate extract block entries currently available in the certificate store for its configuration.

[0093] In one example, the maximum and maximum values ​​provided for a certificate store having subcode 1 may change along with changes in the current configuration, indicated by changes in the certificate store token value. Other variations are possible.

[0094] Returning to Figure 5B, based on storing the storage size information in the verification certificate storage size block 600 (or another information or control block), process 516a returns the verification certificate storage size block (526), ​​assuming that subcode 1 has successfully completed. Furthermore, in one example, process 516a returns response code 422, for example in register R1+1 (528). For example, response code "0001" hex is returned when subcode has successfully completed. Other response codes may be returned, examples of which are described herein.

[0095] Returning to question 520, if it is determined that no verification certificate exists in the certificate store, process 516a sets the verification certificate storage size block length 602 to a defined value, for example, 4. Furthermore, in one example, process 516a returns response code 422 (528) in register R1+1, for example. For example, the response code "0001" hex is returned. Other response codes may be returned.

[0096] In one or more embodiments, the diagnostic "0320" instruction provides a mechanism for retrieving validated certificates and / or validated certificate extracts for a given version of the certificate store for the current configuration. In one example, subcode 1 returns a certificate store token value to the program, which represents the current version of the certificate store for the current configuration. The program stores the returned certificate store token value and provides it as the input certificate store token value to other functions (e.g., subcodes 2 and 3). In one example, the hypervisor returns a certificate store token error response code if the current certificate store token differs from the input certificate store value for the other functions. If the hypervisor returns a certificate store token error response code, the program restarts the above process to retrieve each control block again to ensure that the certificate store token value is consistent for each control block it retrieved from the certificate store for the current configuration. This mechanism allows the hypervisor to ensure that the list of validated certificates and / or validated certificate extracts for this configuration have not changed while it asynchronously retrieves them using subsequent different diagnostic "0320" functions.

[0097] In one or more embodiments, the hypervisor serializes diagnostic "0320" executions, and the certificate store updates so that the current certificate store token value does not change due to changes in the certificate store for the current configuration until all ongoing diagnostic "0320" instruction instances have completed execution. The certificate store token value is not reused until each possible certificate store token value has been used, in one example, to prevent software (e.g., a program) from encountering the same certificate store token value for two different certificate store versions. This process ensures that a program does not encounter updated results while it is asynchronously collecting the validated certificate list and / or validated certificate extract list for the current configuration in a scatter-gather list, for example, by issuing multiple instances of the diagnostic "0320" instruction.

[0098] In one or more embodiments, the diagnostic "0320" instruction returns various storage sizes specific to the verification certificate block and the verification certificate extraction block, including, as an example:

[0099] • The count of verification certificates available in the certificate store for the current configuration (e.g., total verification certificate count 608). Verification certificates and verification certificate extracts are organized, for example, using an index, and the software program has a count of verification certificates and / or verification certificate extracts.

[0100] The maximum singleton verifier certificate block length (e.g., length 616) / maximum singleton verifier certificate extract block length (e.g., length 620) will be used to determine the minimum number of bytes the program will have to obtain a verifier certificate block / verifier certificate extract block that has at least one verifier certificate block entry / verifier certificate extract block entry currently available in the certificate store for the current configuration.

[0101] The total length of the verifying certificate block for the current configuration (e.g., length 618) will be used to determine the minimum number of bytes the program will have to retrieve a verifying certificate block containing all verifying certificate block entries currently available in the certificate store for the current configuration.

[0102] The total length of the verifying certificate extract block for the current configuration (e.g., length 622) will be used to determine the minimum number of bytes the program will have to retrieve a verifying certificate block containing all verifying certificate extract block entries currently available in the certificate store for the current configuration.

[0103] • The number of bytes that can be used depending on the maximum number of verification certificate entries supported by the current machine model (e.g., maximum verification certificate count 610, maximum verification certificate entry length 612).

[0104] The number of bytes that can be used depends on the maximum number of verification certificate extraction entries supported by the current machine model (e.g., maximum verification certificate count 610, maximum verification certificate extraction entry length 614).

[0105] In other examples, additional, lesser, and / or other size / storage size information may be returned.

[0106] In one or more embodiments, the program does not need to continuously check for changes in the list of verifiable certificates and / or the list of verifiable certificate extracts for the current configuration, thereby speeding up and simplifying the checking process and eliminating some coding effort and testing by each operating system. The hypervisor does not need to waste time forming and returning data that will be discarded by the program, thereby reducing execution time. The operating system has the freedom to choose from multiple memory management schemes that best works for each operating system to manage its memory. By using a dynamically updatable certificate store (rather than firmware-embedded certificates), customers can easily update the certificate store with new verifiable certificates when new certificates are available and will be used to verify signed code components.

[0107] In addition to subcode 1, the diagnostic instruction 400 may specify other subcodes, including subcode 2, according to one aspect of the present invention. Further details regarding subcode 2 are described below.

[0108] Subcode 2 - Validation Certificate Storage

[0109] In one or more embodiments, a program (e.g., a bootloader, operating system, or other program) may use diagnostic subcode 2 to directly retrieve a verification certificate (which stores verification keys). Subcode 2 is used to discover one or more verification certificates and specific verification certificate-related information currently present in the certificate store for the current configuration. In one example, the verification key within the verification certificate is used to perform signature verification.

[0110] In one example, the diagnostic "0320" subcode 2 feature is valid when the certificate store facility is installed on one specific architecture and architecture mode (e.g., the z / Architecture instruction set architecture in architecture mode). This check does not need to be performed for other architectures, and / or other architectures may perform other checks. Many possibilities exist.

[0111] In one example, the logical address of the Certificate Validation Block (VCB) is generated under the control of the current addressing mode. The logical address is specified, for example, on a 4K byte boundary; otherwise, in one example, a specification exception is recognized. The Certificate Validation Block, one example of which is described below, may be, for example, multiple times the length of 4K bytes. The length of the Certificate Validation Block is specified, for example, by the Certificate Validation Block Input Length field in word 0 of the Certificate Validation Block, for example, multiple times the length of 4K bytes.

[0112] The verification certificate block includes, for example, output data returned by diagnostic subcode "0320" if the operation completes successfully. It includes, for example, a common header followed by zero or more verification certificate entries (VCEs).

[0113] In one example, the specified first verification certificate index (FVCI) and last verification certificate index (LVCI) provide the range of verification certificates to be stored by the verification certificate storage function. In one example, the count of verification certificate entries stored in a verification certificate block is stored in the stored verification certificate count (SVCC) field of the verification certificate block. Storing partial verification certificate entries is not supported in one example.

[0114] In one example, if no verification certificate exists for a specified verification certificate index range or for the configuration in general, the verification certificate block output length is set to a defined value, e.g., 64. The stored verification certificate count is set to zero, e.g., the remaining verification certificate counts are set to zero, e.g., and the response code 422, e.g., 0001hex, is returned at bit positions 48-63 of general-purpose register R1+1.

[0115] In one example, if the verifier block input length field does not provide sufficient storage to store at least the first requested verifier certificate entry, none of the requested verifier certificate entries are stored, and the verifier block output length (in the verifier certificate block) is set to a defined value, e.g., 64. The stored verifier certificate count is set to zero, e.g., and the remaining verifier certificate count is set to the count of the verifier certificate entries that could not be stored in the verifier certificate block, e.g., and a response code 422 of 0001hex is returned, e.g., at bit positions 48-63 of the general-purpose register R1+1.

[0116] In one example, if the validation certificate block input length field does not provide sufficient storage to store the requested validation certificate entries, the maximum number of validation certificate entries that can fit in the validation certificate block is stored in the validation certificate block's stored validation certificate count (SVCC), and the count of validation certificate entries that could not be stored in the validation certificate block is stored in the validation certificate block's remaining validation certificate count (RVCC) field.

[0117] During operation, in one example, subcode 2 (i.e., execution of a diagnostic instruction 400 having subcode 432 set to 2) is used, for example, by a program to directly retrieve a verification certificate (which stores the verification key). Subcode 2 is used to discover one or more verification certificates and specific verification certificate-related information currently present in the certificate store for the current configuration. In one example, the program specifies the first and last verification certificates it desires, and a certificate store token, and subcode 2 provides a verification certificate block output length corresponding to the amount of memory the program has that can be used, for example, for the firmware to return certificates from a specified range, if any exist.

[0118] In one example, the diagnostic "0320" instruction, subcode 1 (validation certificate storage information query), previously returned the number of validation certificates in the machine's common validation certificate store, and in one example, there is no gap between the index of the first validation certificate and the index of the last validation certificate. Therefore, the specifications of the first and last validation certificates, assuming that the certificates fit in memory provided to, for example, the firmware, allow the requesting program to retrieve the validation certificate it desires. If desired, the program can repeatedly issue the diagnostic "0320" subcode 2 instruction until it finally causes the firmware to return, for example, all the validation certificates in the machine's common certificate store for the current configuration.

[0119] The supplied certificate store token (used, for example, as the output of subcode 1 and as the input to subcode 2) must match the current certificate token. In one example, an error is returned if the supplied certificate store token does not match the current value. This then provides a simple technique to ensure that the validated certificate in the machine's common certificate store has not changed since the diagnostic "0320" instruction subcode 1 was issued, including any previous diagnostic "0320" instruction subcode 2 behavior that was similarly issued.

[0120] In one example, if no verification certificates exist within the specified range, the diagnostic result "0320" subcode 2 returned by the machine's firmware will indicate this. If verification certificates exist within the specified range, the returned information will include, for example, the number of returned verification certificate entries, starting with the verification certificate in the first verification certificate index. This number will be the smaller of either the actual number of verification certificates in the specified range or the number that will fit in the provided memory.

[0121] Each verification certificate entry includes, for example, the actual verification certificate (VC), and for example, the verification certificate index, the verification certificate name provided by the user when it was imported into the machine's common certificate store, and / or other information related to the verification certificate, as described herein.

[0122] In one or more embodiments, a program (e.g., a bootloader, operating system, etc.) issues a diagnostic "0320" instruction specifying subcode 2, a validator certificate entry range, and a certificate store token to retrieve one or more validator certificates in the certificate store for the current configuration. The hypervisor, in one example, returns an error if the current certificate store token for the certificate store for the current configuration differs from the specified certificate store token value. This mechanism allows the hypervisor to ensure that the list of validator certificates for this configuration has not changed between the time it retrieves them asynchronously using this and subsequent diagnostic "0320" function for the same certificate store version, as represented by the certificate store token value for the current configuration. This technique eliminates the need for the program to check the current certificate store token value against the returned / stored certificate store token value (obtained from diagnostic "0320" subcode 1) to determine whether one or more validator certificates have changed.

[0123] In one embodiment, the diagnostic "0320" instruction returns one or more verification certificates in the certificate store for the current configuration, based on the range of verification certificate entries. One or more verification certificates are returned in a verification certificate block, which includes, for example, a header followed by one or more verification certificate entries. The header includes, for example, a specified first verification certificate index and a specified last verification certificate index, which will be used to determine the range of verification certificates to be stored by the verification certificate storage function; and a count of verification certificate entries (VCEs) stored in the verification certificate block. If sufficient storage is not provided in the verification certificate block input length field to store the requested verification certificate entries, a count of the verification certificate entries that could not be stored in the verification certificate block is, in one example, stored in the Remaining Verification Certificate Count (RVCC) field.

[0124] Each verification certificate block entry contains information for, for example, one verification certificate.

[0125] Further details regarding the verification certificate block and verification certificate entries are explained with reference to Figures 7A and 7B. In one example, the verification certificate block 700 (Figure 7A) contains a common header (e.g., 16 words) followed by zero or more verification certificate entries (VCEs). In one example, selected locations in the common header (e.g., words 0-7) contain input data, and other selected locations in the common header (e.g., words 8-15) contain output data. In one example, subcode 2 stores the list of verification certificates in the certificate format in the verification certificate block.

[0126] In one example, verification certificate block 700 includes the following fields:

[0127] Verification Certificate Block (VCB) Input Length 702: This field (e.g., word 0) contains an unsigned binary integer (e.g., 32 bits) specifying the number of bytes in the verification certificate block. In one example, this value is a non-zero multiple of, for example, 4K; otherwise, a response code 422 of, for example, 0204hex is returned, for example, at bit positions 48-63 of general-purpose register R1+1.

[0128] The first verifier certificate index 704: This field (e.g., bytes 0-1 of word 2) contains an unsigned binary integer (e.g., 16 bits) that specifies the index of the verifier certificate in the certificate store that will be stored in the first verifier certificate entry. In one example, this value is less than or equal to the value of the last verifier certificate index; otherwise, a response code 422, e.g., 0302hex, is returned, e.g., at bit positions 48-63 of general-purpose register R1+1.

[0129] Last Validation Certificate Index 706: This field (e.g., bytes 2-3 of word 2) contains an unsigned binary integer (e.g., 16 bits) that specifies the index of the validation certificate in the certificate store that will be stored in the last validation certificate entry.

[0130] In one example, a value of zero is a valid index for the first and / or last validated certificate index for this instruction. However, since the certificate store maintains one origin for indexes, no certificates are available for index value zero. A request for a single certificate with index zero results in a returned certificate of zero. A request for multiple certificates starting at zero results in a first returned certificate entry storing a certificate index of 1.

[0131] Certificate Store (CS) Token 708: This field (e.g., word 4) contains an unsigned binary integer (e.g., 32 bits) specifying the version of the verification certificate that will be stored in the verification certificate entry. If the specified certificate store token value does not match the current certificate store token value in the certificate store for that configuration, a response code 422, e.g., 0306hex, is returned, e.g., at bit positions 48-63 of general-purpose register R1+1.

[0132] Verification Certificate Block Output Length 710: This field (e.g., word 8) contains an unsigned binary integer (e.g., 32 bits) that specifies the total number of bytes in the verification certificate block if the operation completes successfully. In one example, this value is greater than or equal to 64, for example.

[0133] Version 712: This field (e.g., byte 3 of word 9) contains an unsigned binary integer (e.g., 8 bits) specifying the version number for the verification certificate block. This field is set to zero, for example.

[0134] Stored Verification Certificate Count 714: This field (e.g., bytes 0-1 of word 10) contains the unsigned integer (e.g., 16-bit) count of the verification certificates stored in the verification certificate block.

[0135] Remaining Validation Certificate Count 716: This field (e.g., bytes 2-3 of word 10) contains the unsigned integer (e.g., 16-bit) count of Validation Certificates that could not be stored in the Validation Certificate Block due to insufficient storage as specified in the Validation Certificate Block Input Length field.

[0136] Validation Certificate Entry 718: In one example, a validation certificate block (e.g., word 16-N) may contain zero or more validation certificate entries based on the validation certificate block input length and validation certificate range (e.g., from the first validation certificate index to the last validation certificate index) currently in the certificate store for its configuration. In one example, a validation certificate entry has a common header that the validation certificates in the certificate format are followed by.

[0137] In one example, each verification certificate entry is aligned, for example, by word alignment. Each variable-length field within a verification certificate entry is also aligned, for example, by word alignment. In one example, to provide word boundary alignment, for example, gaps are formed between verification certificate entries using a verification certificate entry length that is, for example, multiples of 4, and between verification certificate entry fields using a verification certificate entry field offset that is, for example, multiples of 4. The verification certificate entry field length includes a value that is, for example, the actual size of the verification certificate entry field, and the unused area (gap) following the verification certificate entry field stores, for example, multiple zeros.

[0138] In one example, each variable-length field within a verification certificate entry has an offset and a length. The offset of a variable-length field is used to locate that field, and the length of the variable-length field is used to determine the number of bytes stored in that field.

[0139] In one example, as shown in Figure 7B, the verification certificate entry 718 includes the following fields:

[0140] Verification Certificate Entry Length 730: This field (e.g., word 0) contains an unsigned binary integer (e.g., 32 bits) that specifies the total number of bytes in the verification certificate entry. The value of the Verification Certificate Entry Length field can be multiples of, for example, 4 bytes.

[0141] Verification certificate entry flag 732: This field (for example, byte 0 of word 1) contains a flag field defined as follows in one example: Bit meaning 0 Valid Verification Certificate (VCV): If bit 0 is, for example, 1, The verification certificate is valid for this configuration. • The verification certificate entry contains the verification certificate. If the bit is zero, for example, • The verification certificate is invalid for this configuration. The verification certificate entry length is set to, for example, 72. 1-7 Reservations

[0142] Key Type 734: This field (e.g., Byte 1 of Word 1) contains an unsigned binary integer (e.g., 8 bits) that specifies the key type of the public key used to verify the signature of one or more signed binary code components.

[0143] The key type field value is defined as follows in one example: Value Meaning 0 Unsupported key types 1. ECDSA (Elliptic Curve Digital Signature Algorithm) - NIST (National Institute of Standards and Technology) Curve P521 2-255 reservations

[0144] Certificate Index 736: This field (e.g., bytes 2-3 of word 1) contains an unsigned binary integer (e.g., 16 bits) that specifies the index of the current validating certificate in the certificate store for its configuration. It also represents the index of the directly associated validating certificate extract.

[0145] Validation Certificate Name 738: This field (e.g., words 2-17) contains the name (e.g., 64 bytes) of the validation certificate as it appears on a service element (SE) (e.g., a service element may be part of and / or combined with one or more logical partitions and used to facilitate initial program loading). The validation certificate name is, for example, in EBCDIC (Extended Binary Coded Decimal Interchange Code) character format, and is left-aligned with right-side padding in EBCDIC character format. In one example, the validation certificate name is used to identify the validation certificate in the certificate store via the service element panel because the validation certificate index is, for example, an internal mechanism and is not displayed in the service element panel. Other possibilities exist.

[0146] Validation Certificate Format 740: This field (e.g., byte 0 of word 18) contains an unsigned binary integer (e.g., 8 bits) that specifies the format of the validation certificate. The validation certificate format field value is defined as follows in one example: Value Meaning 0 Unsupported verification certificate formats 1. x.509 certificate in DER (Distinguished Encoding Rules) format. 2-255 reservations

[0147] Key ID Length 742: This field (e.g., bytes 2-3 of word 18) contains an unsigned binary integer (e.g., 16 bits) that specifies the number of bytes in the key ID field. The key ID length field value is multiples of, for example, one byte.

[0148] Validation Certificate Hash Type 744: This field (e.g., byte 1 of word 19) contains an unsigned binary integer (e.g., 8 bits) that specifies the hash type of the validation hash (also known as the fingerprint) used to identify the validation certificate. The validation certificate hash type field value is defined as follows in one example: Value Meaning 0 Unsupported verification certificate hash types 1. SHA2-256 (Secure Hash Algorithm) 2-255 reservations

[0149] Verification Certificate Hash Length 746: This field (e.g., bytes 2-3 of word 19) contains an unsigned binary integer (e.g., 16 bits) specifying the number of bytes in the verification certificate hash field. The verification certificate hash length field value can be multiples of, for example, 1 byte.

[0150] Verification Certificate Length 748: This field (e.g., word 21) contains an unsigned binary integer (e.g., 32 bits) specifying the number of bytes in the verification certificate field. The verification certificate length field value can be multiples of, for example, one byte.

[0151] Validation Certificate Hash Offset 750: This field (e.g., bytes 0-1 of word 24) contains an unsigned binary integer (e.g., 16 bits) that specifies the offset of the validation certificate hash field. The validation certificate hash offset field value can be multiples of, for example, 4 bytes.

[0152] Verification Certificate Offset 752: This field (e.g., bytes 2-3 of word 24) contains an unsigned binary integer (e.g., 16 bits) that specifies the offset of the verification certificate field. The verification certificate offset field value can be multiples of, for example, 4 bytes.

[0153] Key ID 754: This field (e.g., word 32-A) contains the key ID used to identify the public key in the verification certificate. The Key ID Length field specifies, for example, the number of bytes in the Key ID field. The Key ID field is word-aligned, for example.

[0154] Validation Certificate Hash 756: This field (e.g., word A+1~B) contains the hash value of the validation certificate (known as a fingerprint), which can be used, for example, to identify the validation certificate in a firmware embedded code implementation. The Validation Certificate Hash Length field specifies, for example, the number of bytes in the Validation Certificate Hash field. The Validation Certificate Hash field is, for example, word-aligned. This data is, for example, in big-endian binary format.

[0155] Verification Certificate 758: This field (e.g., Word B+1~N) contains the verification certificate. The Verification Certificate Length field specifies, for example, the number of bytes in the Verification Certificate field. The Verification Certificate field is, for example, word-aligned.

[0156] In one or more embodiments, the hypervisor and the program work together to ensure that the program can asynchronously retrieve the entire list of validated certificates for the current configuration, for example, in a scatter-gather list for the same certificate store version (same certificate store token value), even if the certificate store token value changes while the program is collecting a partial list of validated certificates by issuing multiple instances of the diagnostic "0320" instruction. The hypervisor detects a certificate store token mismatch based on the certificate store token value specified by the program and terminates the instruction rather than wasting machine processing time by allowing the program to construct a response that discards and restarts the validated certificate collection process.

[0157] The diagnostic "0320" instruction locates each verification certificate from the certificate store for the current configuration based on the verification certificate entry range and returns it as a verification certificate entry in the verification certificate format. The return of the verification certificates is further illustrated with reference to Figures 5A and 5C.

[0158] In one example, referring to Figure 5A, process 500 executes the diagnostic "0320" subcode 2 function (516) based on decision 514 that the diagnostic "0320" subcode 2 function will be executed. Further details regarding the execution of the function to store the verification certificate (subcode 2) are explained with reference to Figure 5C.

[0159] In one embodiment, process 516b determines, for example, the range of verification certificates to be stored in a verification certificate block (540). For example, a specified first verification certificate index (e.g., index 704 obtained from verification certificate block 700 entered into the instruction) and a specified last verification certificate index (e.g., index 706 obtained from verification certificate block 700) provide the range of verification certificates to be stored by the verification certificate storage function.

[0160] Process 516b determines whether a verification certificate exists in the certificate store for a specified range or for the requested configuration in general (542). If one or more verification certificates exist in the certificate store for the specified range for the requested configuration, process 516b further determines whether the certificate store token supplied as input to, for example, subcode 2, matches the current certificate store token for the requested configuration (543). In one example, if the supplied certificate store token value matches the current certificate store token value, process 516b further determines whether there is sufficient storage in the verification certificate block for at least one verification certificate entry (e.g., verification certificate) in the verification certificate block (544). If there is sufficient storage in the verification certificate block for at least one verification certificate entry, process 516b stores one or more verification certificates from the certificate store in the verification certificate block (546). Furthermore, process 516b stores a count of the number of verification certificates stored in the verification certificate block (e.g., count 714) (548).

[0161] Process 516b determines whether there is enough storage in the certificate validation block to store the requested certificate validation entries (552). If there is insufficient storage in the certificate validation block to store the requested certificate validation entries, in one example, process 516b sets the stored certificate validation count (e.g., count 714) in the certificate validation block to the number of entries stored in the certificate validation block (556), and sets the remaining certificate validation count (e.g., count 716) in the certificate validation block to the number of requested entries that could not be stored (558).

[0162] Process 516b returns a response code of 0001hex (e.g., response code 422) in one example (560).

[0163] Returning to question 552, if there is sufficient storage to store the requested verification certificate, process 516b will return a response code of 0001hex (e.g., response code 422) (560), for example in one example.

[0164] Returning to question 542, if no verification certificate exists for the specified range or configuration, process 516b sets the verification certificate block output length (e.g., length 710) to a defined length (e.g., 64) (562); sets the stored verification certificate count (e.g., count 714) to zero (556); and sets the remaining verification certificate count (e.g., count 716) to zero (558). Process 516b returns a response code (e.g., response code 422) of 0001hex (560).

[0165] Furthermore, returning to question 543, if the supplied certificate store token value does not match the current certificate store token value, process 516b returns a response code indicating an error, for example 0306hex (e.g., response code 422).

[0166] Furthermore, returning to question 544, if, for example, sufficient storage is not indicated in the verification certificate block input length 702 to store at least the first requested verification certificate, then none of the requested verification certificate entries will be stored, and process 516b will set the verification certificate block output length 710 to a defined value (e.g., 64) (562); set the stored verification certificate count 714 to, for example, zero (556); and set the remaining verification certificate count 716 to, for example, the count of verification certificate entries that could not be stored (558). Process 516b will return a response code (e.g., response code 422) (560).

[0167] In one or more embodiments, the program does not need to continuously check for changes in the list of verification certificates for the current configuration, thereby speeding up the checking process and eliminating some coding effort and testing by each software. The hypervisor does not waste processing time building responses that the program would discard in any way. The program has the freedom to retrieve verification certificate entries using an entry range that matches its storage management scheme that works best for each software. By using a dynamically updatable certificate store (rather than firmware-embedded certificates), customers can easily update the certificate store with new verification certificates when new certificates become available to verify signed code components. For example, a mechanism is provided to associate and display verification certificates in the certificate store, for example, via a service element panel, using verification certificates retrieved by the software using the verification certificate name and verification certificate index. The program can internally associate verification certificates using, for example, the verification certificate name, key ID, fingerprint, and / or verification certificate index.

[0168] In addition to subcodes 1 and 2, the diagnostic instruction 400 may specify other subcodes, including subcode 3, according to one aspect of the present invention. Further details regarding subcode 3 are described below.

[0169] Subcode 3 - Extract and store verification certificates

[0170] In one or more embodiments, a program (e.g., a bootloader, operating system, or other program) may use diagnostic subcode 3 to retrieve extracted verification key material (in a format that is easy to consume) that is currently in the certificate store for the current configuration. This is particularly useful, for example, when the program cannot directly parse the certificate to retrieve the verification key material.

[0171] In one example, subcode 3 provides a Verification Certificate Extract (VCX) located in the certificate store for its configuration. The verification key within the Verification Certificate Extract is used to perform signature verification.

[0172] In one example, diagnostic "0320" subcode 3 is valid when the certificate store facility is installed on one specific architecture and architecture mode (e.g., the z / Architecture instruction set architecture in architecture mode). This check does not need to be performed for other architectures, and / or other architectures may perform other checks. Many possibilities exist.

[0173] In one example, the logical address of the Certificate Validation Extract Block (VCXB) is generated under the control of the current addressing mode. The logical address is specified, for example, on a 4K byte boundary; otherwise, in one example, a specification exception is recognized. The Certificate Validation Extract Block may be, for example, several times the length of 4K bytes. The length of the Certificate Validation Extract Block is specified, for example, several times the length of 4K bytes, by the Certificate Validation Extract Block Input Length field in word 0 of the Certificate Validation Extract Block.

[0174] The Certificate Validation Extraction block includes, for example, output data returned by diagnostic subcode 3 "0320" if the operation completes successfully. It includes, for example, a common header, followed by zero or more Certificate Validation Extraction Entries (VCXEs).

[0175] In one example, the specified first verification certificate extract index (FVCXI) and the specified last verification certificate extract index (LVCXI) provide the range of verification certificate extracts that will be stored by the verification certificate extract storage function. In one example, the count of verification certificate extract entries stored in a verification certificate extract block is stored in the stored verification certificate extract count (SVCXC) field of the verification certificate extract block. Storing partial verification certificate extract entries is not supported in one example.

[0176] In one example, if no verification certificate extract exists for the specified verification certificate extract index range or for the configuration in general, the verification certificate extract block output length is set to a defined value, e.g., 64. The stored verification certificate extract count is set to zero, e.g., the remaining verification certificate extract count (RVCXC) is set to zero, e.g., the response code 422, e.g., 0001hex, is returned at bit positions 48-63 of the general-purpose register R1+1.

[0177] In one example, if sufficient storage is not provided in the Certificate Extract Block Input Length field to store at least the first requested Certificate Extract entry, none of the requested Certificate Extract entries are stored, and the Certificate Extract Block Output Length is set to a defined value, e.g., 64. The stored Certificate Extract count is set to zero, e.g., and the remaining Certificate Extract count is set to the count of Certificate Extract entries that could not be stored in the Certificate Extract Block, e.g., and a response code 422 of 0001hex is returned, e.g., at bit positions 48-63 of the general-purpose register R1+1.

[0178] In one example, if the Certificate Extract Block Input Length field does not provide sufficient storage to store the requested Certificate Extract entries, the maximum number of Certificate Extract entries that can fit in the Certificate Extract Block is stored in the Certificate Extract Block's Stored Certificate Extract Count field, and the count of Certificate Extract entries that could not be stored in the Certificate Extract Block is stored in the Certificate Extract Block's Remaining Certificate Extract Count field.

[0179] During operation, in one example, subcode 3 (i.e., execution of a diagnostic instruction 400 having subcode 432 set to 3) is used, for example, by a program to retrieve extracted verification key material (e.g., in an easily consumable format) that is currently in the certificate store for the current configuration. In one example, the program specifies the first and last verification certificate extracts it desires, and the certificate store token, and subcode 3 provides a verification certificate extract block output length corresponding to the amount of program memory that the firmware can use to return certificate extracts from a specified range, if present.

[0180] In one example, the diagnostic "0320" instruction, subcode 1 (validation certificate storage information query), previously returned the number of validation certificates, which in one example is equal to the number of validation certificate extracts in the machine's common validation certificate store. Thus, the specifications of the first and last validation certificate extracts, assuming that the certificate extracts fit within the memory provided to, for example, the firmware, allow the requesting program to obtain the validation extracts it desires. If desired, the program can repeatedly issue the diagnostic "0320" subcode 3 instruction to eventually cause the firmware to return, for example, all the validation certificate extracts in the machine's common certificate store for the current configuration.

[0181] The supplied certificate store token (used, for example, as the output of subcode 1 and as the input to subcode 3) must match the current certificate token. In one example, an error is returned if the supplied certificate store token does not match the current value. This then provides a simple technique to ensure that the verifying certificate (and therefore the verifying certificate extract) in the common certificate store on the machine has not changed since the diagnostic "0320" instruction subcode 1 was issued, including any previous diagnostic "0320" instruction subcode 3 operations that were similarly issued.

[0182] In one example, if no validation certificate extracts exist within the specified range, the diagnostic result "0320" subcode 3 returned by the machine's firmware will indicate this. If validation certificate extracts exist within the specified range, the returned information will include, for example, the number of returned validation certificate extract entries, starting with the validation certificate extract in the first validation certificate extract index. This number will be the smaller of either the actual number of validation certificate extracts within the specified range or the number that will fit in the provided memory.

[0183] In one example, verification key material is extracted only for a specific verification key type. Verification certificate extraction does not need to exist for all verification certificates. In such an implementation, verification certificate extraction entries are not compressed to remove entries that do not have a valid verification certificate extraction. Instead, verification certificate extraction entries that do not have a valid verification certificate extraction are considered invalid and are indicated in the header and the verification certificate extraction entry that stores only the Verification Certificate Extract Enabled (VCXV) flag, for example, set to zero. For example, a verification certificate extraction entry stores the actual verification certificate extraction information if the corresponding verification certificate stores one of the key types from which the verification key material is extracted. This information includes, for example, the time when the verification certificate was first valid, the last time the verification certificate was valid, information about the verification certificate, information about the type of verification key, and the extracted verification key block (XVKB) that stores the actual variable-size verification key.

[0184] In one or more embodiments, a program (e.g., a bootloader, operating system, etc.) issues a diagnostic "0320" instruction specifying subcode 3, a range of verified certificate extract entries, and a certificate store token to retrieve one or more verified certificate extracts in the certificate store for the current configuration. The hypervisor, in one example, returns an error if the current certificate store token for the certificate store for the current configuration differs from the specified certificate store token value. This mechanism allows the hypervisor to ensure that the list of verified certificate extracts for this configuration has not changed between the time it retrieves them asynchronously using this and subsequent diagnostic "0320" function for the same certificate store version, as represented by the certificate store token value for the current configuration. This technique eliminates the need for the program to check the current certificate store token value against the returned / stored certificate store token value (obtained from diagnostic "0320" subcode 1) to determine whether one or more verified certificates have changed.

[0185] In one embodiment, the diagnostic "0320" instruction returns one or more verifying certificate extracts in the certificate store for the current configuration, based on the range of verifying certificate extract entries. One or more verifying certificate extracts are returned in a verifying certificate extract block, which includes, for example, a header followed by one or more verifying certificate extract entries. The header includes, for example, a specified first verifying certificate extract index and a specified last verifying certificate index, which will be used to determine the range of verifying certificate extracts to be stored by the verifying certificate extract storage function; and a count of the verifying certificate extract entries (VCXEs) stored in the verifying certificate extract block. If sufficient storage is not provided in the verifying certificate extract block input length field to store the requested verifying certificate extract entries, a count of the verifying certificate extract entries that could not be stored in the verifying certificate extract block is, in one example, stored in the remaining verifying certificate extract count field.

[0186] Each verification certificate extraction block entry contains, for example, information for extracting one verification certificate.

[0187] Further details regarding the certificate extraction block and certificate extraction entries are explained with reference to Figures 8A and 8B. In one example, the certificate extraction block 800 (Figure 8A) contains a common header (e.g., 16 words) followed by zero or more certificate extraction entries (VCXEs). In one example, selected locations in the common header (e.g., words 0-7) contain input data, and other selected locations in the common header (e.g., words 8-15) contain output data. In one example, subcode 3 stores the certificate extraction list in the extracted key type format in the certificate extraction block.

[0188] In one example, the verification certificate extraction block 800 contains the following fields:

[0189] Verification Certificate Extraction Block (VCXB) Input Length 802: This field (e.g., word 0) contains an unsigned binary integer (e.g., 32 bits) specifying the number of bytes in the Verification Certificate Extraction Block. In one example, this value is a non-zero multiple of, for example, 4K; otherwise, a response code 422 of, for example, 0206hex is returned, for example, at bit positions 48-63 of general-purpose register R1+1.

[0190] The first verifying certificate extraction index 804: This field (e.g., bytes 0-1 of word 2) contains an unsigned binary integer (e.g., 16 bits) that specifies the index of the verifying certificate extraction in the certificate store, which will be stored in the first verifying certificate extraction entry. In one example, this value is less than or equal to the value of the last verifying certificate extraction index; otherwise, a response code 422, e.g., 0304hex, is returned, e.g., at bit positions 48-63 of general-purpose register R1+1.

[0191] Last Validation Certificate Extraction Index 806: This field (e.g., bytes 2-3 of word 2) contains an unsigned binary integer (e.g., 16 bits) that specifies the index of the validation certificate extraction in the certificate store that will be stored in the last validation certificate extraction entry.

[0192] In one example, a value of zero is a valid index for the first and / or last validated certificate extract index for this instruction. However, since the certificate store maintains one origin for indexes, no certificate extracts are available for index value zero. A request for a single certificate extract with index zero results in zero returned certificate extracts. A request for multiple certificate extracts starting at zero results in a first returned certificate extract entry storing certificate index 1.

[0193] Certificate Store (CS) Token 808: This field (e.g., word 4) contains an unsigned binary integer (e.g., 32 bits) specifying the version of the verified certificate extract that will be stored in the verified certificate extract entry. If the specified certificate store token value does not match the current certificate store token value in the certificate store for that configuration, a response code 422, e.g., 0306hex, is returned, e.g., at bit positions 48-63 of general-purpose register R1+1.

[0194] Verification Certificate Extraction Block Output Length 810: This field (e.g., word 8) contains an unsigned binary integer (e.g., 32 bits) that specifies the number of bytes returned in the verification certificate extraction block if the operation completes successfully. In one example, this value is greater than or equal to 64, for example.

[0195] Version 812: This field (e.g., byte 3 of word 9) contains an unsigned binary integer (e.g., 8 bits) specifying the version number for the verification certificate extraction block. This field is set to zero, for example.

[0196] Stored Verification Certificate Extraction Count 814: This field (e.g., bytes 0-1 of word 10) contains the unsigned integer (e.g., 16-bit) count of the verification certificate extracts stored in the verification certificate extraction block.

[0197] Remaining Validation Certificate Extraction Count 816: This field (e.g., bytes 2-3 of word 10) contains the unsigned integer (e.g., 16-bit) count of Validation Certificate Extracts that could not be stored in the Validation Certificate Extraction block due to insufficient storage as specified in the Validation Certificate Extraction Block Input Length field.

[0198] Validation Certificate Extraction Entry 818: In one example, a validation certificate extraction block (e.g., word 16~N) may store zero or more validation certificate extraction entries based on the validation certificate extraction block input length and validation certificate extraction range (e.g., from the first validation certificate extraction index to the last validation certificate extraction index) currently in the certificate store for its configuration. In one example, a validation certificate extraction entry has a common header that follows the validation certificate extraction in the extracted key type format.

[0199] In one example, each certificate of verification extraction entry is aligned, for example, by word alignment. Each variable-length field within a certificate of verification extraction entry is also aligned, for example, by word alignment. In one example, to provide word boundary alignment, for example, gaps are formed between certificate of verification extraction entries using a certificate of verification extraction entry length that is, for example, multiple times 4, and between certificate of verification extraction entry fields using a certificate of verification extraction entry field offset that is, for example, multiple times 4. The certificate of verification extraction entry field length includes a value that is, for example, the actual size of the certificate of verification extraction entry field, and the unused area (gap) following the certificate of verification extraction entry field stores, for example, multiple zeros.

[0200] In one example, each variable-length field within a certificate validation entry has an offset and a length. The offset of a variable-length field is used to locate that field, and the length of the variable-length field is used to determine the number of bytes stored in that field.

[0201] In one example, as shown in Figure 8B, the verification certificate extraction entry 818 includes the following fields:

[0202] Verification Certificate Extraction Entry Length 830: This field (e.g., word 0) contains an unsigned binary integer (e.g., 32 bits) that specifies the total number of bytes in the verification certificate extraction entry. The value of the verification certificate extraction entry length field can be multiples of, for example, 4 bytes.

[0203] Verification Certificate Extraction Entry Flag 834: This field (e.g., byte 0 of word 1) contains a flag field defined as follows in one example: Bit meaning 0 Validation certificate extraction enabled (VCXV): If bit 0 is, for example, 1, • Certificate validation is effective for this configuration. • The validation certificate extraction entry contains the validation certificate. If the bit is zero, for example, • Certificate validation is disabled for this configuration. The length of the verification certificate extraction entry is set to, for example, 72. 1-7 Reservations

[0204] In one example, the valid certificate extract enabled flag is used to indicate that valid certificate extracts are disabled for this configuration, rather than being removed by the hypervisor each time they are retrieved from the machine by compressing the valid certificate extract storage and renumbering them using different index values ​​for all currently valid valid certificate extracts (holes).

[0205] In one example, if the verification certificate extraction is invalid (VCXV=0), the program can perform the following actions to determine whether it is actually invalid:

[0206] • Fine-grained error detection for one function using another function:

[0207] Subcode 3 indicates that the verification certificate extraction entry is invalid (unsupported key type).

[0208] The software issues subcode 2 to obtain the actual verification certificate (VC) for which a verification certificate extraction (VCX) was not created.

[0209] If the actual verification certificate (VC) (obtained using subcode 2) is valid and its key type is the same as one of the supported subcode 3 key types, the machine should have generated a verification certificate extract but did not, and therefore an error can be reported by the software.

[0210] Key Type 836: This field (e.g., Byte 1 of Word 1) contains an unsigned binary integer (e.g., 8 bits) that specifies the key type of the public key used to verify the signature of one or more signed binary code components.

[0211] The key type field value is defined as follows in one example: Value Meaning 0 Unsupported key types 1 ECDSA-NIST Curve P521 2-255 reservations

[0212] Certificate Index 840: This field (e.g., bytes 2-3 of word 1) contains an unsigned binary integer (e.g., 16 bits) that specifies the index of the current validation certificate extraction in the certificate store for the current configuration. It also represents the index of the directly associated validation certificate.

[0213] Validation Certificate Name 842: This field (e.g., words 2-17) contains the name (e.g., 64 bytes) of the validation certificate (from which the validation certificate extract was created) as it appears on the Service Element panel. In one example, the validation certificate name is used to identify the validation certificate extract in the certificate store via the service element, for example, because the validation certificate extract index is an internal mechanism and is not displayed on the Service Element panel. Other possibilities exist.

[0214] Key ID Length 844: This field (e.g., bytes 2-3 of word 18) contains an unsigned binary integer (e.g., 16 bits) that specifies the number of bytes in the Key ID field, for example. The Key ID Length field value is multiples of, for example, 1 byte.

[0215] Validation Certificate Hash Type 846: This field (e.g., byte 1 of word 19) contains an unsigned binary integer (e.g., 8 bits) that specifies the hash type of the validation certificate hash (also known as a fingerprint) used to identify the validation certificate from which the extracted material is obtained. The validation certificate hash type field value is defined in one example as follows: Value Meaning 0 Unsupported verification certificate hash types 1. SHA2-256 (Secure Hash Algorithm) 2-255 reservations

[0216] Verification Certificate Hash Length 848: This field (e.g., bytes 2-3 of word 19) contains an unsigned binary integer (e.g., 16 bits) specifying the number of bytes in the verification certificate hash field. The verification certificate hash length field value can be multiples of, for example, 1 byte.

[0217] Extracted Verification Key Block (XVKB) Length 850: This field (e.g., word 21) contains an unsigned binary integer (e.g., 32 bits) specifying the number of bytes in the extracted verification key block field. The extracted verification key block length field value is a multiple of, for example, 4 bytes.

[0218] Validation Certificate Hash Offset 852: This field (e.g., bytes 0-1 of word 24) contains an unsigned binary integer (e.g., 16 bits) that specifies the offset of the validation certificate hash field. The validation certificate hash offset field value is a multiple of, for example, 4 bytes.

[0219] Extracted Verification Key Block Offset 854: This field (e.g., bytes 2-3 of word 24) contains an unsigned binary integer (e.g., 16 bits) that specifies the offset of the extracted verification key block field. The extracted verification key block offset field value is, for example, multiples of 4 bytes.

[0220] Verification Certificate Validity Start Time 856: This field (e.g., words 32-33) contains the TOD (time of day) clock point (e.g., the leftmost 8 bytes of the clock memory extension instruction output from which the verification certificate becomes valid). In one example, the time range is used to ensure that the verification certificate extract is valid and can be used to verify signed binary code components.

[0221] Verification certificate expiration date 858: This field (e.g., words 34-35) contains the TOD clock time (e.g., the leftmost 8 bytes of the clock memory extension instruction output from which the verification certificate becomes invalid).

[0222] Key ID 860: This field (e.g., words 48-A) contains the key ID used to identify the public key in the verification certificate. The Key ID Length field specifies, for example, the number of bytes in the Key ID field. The Key ID field is word-aligned, for example.

[0223] Validation Certificate Hash 862: This field (e.g., word A+1~B) contains the hash value (known as a fingerprint) of the validation certificate (from which the validation certificate extract was created) that can be used to identify the validation certificate in the firmware embedded code implementation. The Validation Certificate Hash Length field specifies, for example, the number of bytes in the Validation Certificate Hash field. The Validation Certificate Hash field is, for example, word-aligned. This data is, for example, in big-endian binary format.

[0224] Extracted Verification Key Block 864: This field of the Verification Certificate Extraction Entry (e.g., word B+1~N) contains the extracted verification key block (XVKB). In one example, the extracted verification key block has one or more verification key parts of the specified key type. Each extracted verification key block is aligned, e.g., word-aligned. Each variable-length field within the extracted verification key block is also aligned, e.g., word-aligned. In one example, gaps are formed between extracted verification key blocks using an extracted verification key block length that is, e.g., multiple times 4, and between extracted verification key block fields using an extracted verification key block field offset that is, e.g., multiple times 4, to provide word boundary alignment. The extracted verification key block field length contains a value that is the actual size of the extracted verification key block field, and any unused area (gaps) following the extracted verification key block field stores, e.g., multiple zeros.

[0225] In one example, each variable-length field within the extracted validation key block has an offset and a length. The offset of a variable-length field is used to locate that variable-length field, and the length of the variable-length field is used to determine the number of bytes stored in the variable-length field.

[0226] In one example, if the specified key type is set to, for example, 0 (an unsupported key type), the extracted verification key block will contain, for example, unformatted verification key data. The extracted verification key block length field in the verification certificate extraction entry contains the number of bytes stored in the extracted verification key block field.

[0227] In one example, if the specified key type is set to, for example, 1 (ECDSA-NIST Curve P521), the Elliptic Curve Verification Key Block (ECVKB) shows the format of the verification key.

[0228] An example of an elliptic curve validation keyblock is illustrated with reference to Figure 8C. In this example, the elliptic curve validation keyblock 880 includes, for example, the following fields:

[0229] Verification key section X length 882: This field (e.g., bytes 0-1 of word 0) contains an unsigned binary integer (e.g., 16 bits) that specifies the number of bytes in the verification key section X field. The value of the verification key section X length field is, for example, multiples of 4 bytes.

[0230] Verification key Y length 884: This field (e.g., bytes 2-3 of word 0) contains an unsigned binary integer (e.g., 16 bits) that specifies the number of bytes in the verification key Y field. The verification key Y length field value is, for example, multiples of 4 bytes.

[0231] Verification Key X886: This field (e.g., words 1-D) contains the value of the first verification key (the X component of a point on an elliptic curve). The Verification Key X Length field contains, for example, the number of bytes in the Verification Key X field. The Verification Key X field is aligned, for example, word-aligned. This data is, for example, in big-endian binary format.

[0232] Verification Key Y888: This field (e.g., word D+1~N) contains the value of the second signature key (the Y component of a point on an elliptic curve). The Verification Key Y Length field contains, for example, the number of bytes in the Verification Key Y field. The Verification Key Y field is aligned, for example, word-aligned. This data is, for example, in big-endian binary format.

[0233] In one or more embodiments, the hypervisor and the program work together to ensure that the program can asynchronously obtain the entire list of verified certificates for the current configuration, for example, in a scatter-gather list for the same certificate store version (same certificate store token value), even if the certificate store token value changes while collecting a partial list of verified certificates by issuing multiple instances of the diagnostic "0320" instruction. The hypervisor detects a certificate store token mismatch based on the certificate store token value specified by the program and terminates the instruction rather than wasting machine processing time by allowing the program to construct a response that discards and restarts the verified certificate extraction collection process.

[0234] The diagnostic command "0320" locates each verification certificate of a key type extracted from the certificate store for the current configuration, parses and extracts the verification key material from the verification certificates, and returns them to the verification certificate extraction entries in the verification certificate extraction format based on the verification certificate extraction entry range. The return of the verification certificate extraction is further explained with reference to Figures 5A and 5D.

[0235] In one example, referring to Figure 5A, process 500 executes the diagnostic "0320" subcode 3 function (516) based on decision 514 that the function will be executed. Further details regarding the execution of the function to store the verification certificate extraction (subcode 3) are explained with reference to Figure 5D.

[0236] In one embodiment, process 516c determines the range of verification certificate extracts that will be stored in, for example, a verification certificate extract block (570). For example, a specified first verification certificate extract index (e.g., index 804 obtained from verification certificate extract block 800 entered into the instruction) and a specified last verification certificate index (e.g., index 806 obtained from verification certificate block 800) provide the range of verification certificate extracts that will be stored by the verification certificate extract storage function.

[0237] Process 516c determines whether a verifying certificate extract exists in the certificate store for a specified range or for the requested configuration in general (572). If one or more verifying certificate extracts exist in the certificate store for a specified range for the requested configuration, process 516c further determines whether the certificate store token supplied as input to, for example, subcode 3, matches the current certificate store token for the requested configuration (573). In one example, if the supplied certificate store token value matches the current certificate store token value, process 516c further determines whether there is sufficient storage in the verifying certificate extract block for at least one verifying certificate extract entry (e.g., verifying certificate extract) (574). If there is sufficient storage in the verifying certificate extract block for at least one verifying certificate extract entry, process 516c stores one or more verifying certificate extracts from the certificate store in the verifying certificate extract block (576). Furthermore, process 516c stores a count of the number of verifying certificate extracts stored in the verifying certificate extract block (e.g., count 814) (578).

[0238] Process 516c determines whether there is sufficient storage in the certificate validation block to store the requested certificate validation entries (582). If there is insufficient storage in the certificate validation block to store the requested certificate validation entries, in one example, process 516c sets the stored certificate validation count (e.g., count 814) in the certificate validation block to the number of extraction entries stored in the certificate validation block (586), and sets the remaining certificate validation count (e.g., count 816) in the certificate validation block to the number of requested extraction entries that could not be stored (588).

[0239] Process 516c returns a response code of 0001hex (e.g., response code 422) in one example (590).

[0240] Returning to question 582, if there is sufficient storage to store the requested verification certificate extraction, process 516c will return a response code of 0001hex (e.g., response code 422) (590), for example in one example.

[0241] Returning to question 572, if no verification certificate extract exists for the specified range or configuration, process 516c sets the verification certificate extract block output length (e.g., length 810) to a defined length (e.g., 64) (592); sets the stored verification certificate extract count (e.g., count 814) to zero (586); and sets the remaining verification certificate extract count (e.g., count 816) to zero (588). Process 516c returns a response code (e.g., response code 422) for example 0001hex (590).

[0242] Furthermore, returning to question 573, if the supplied certificate store token value does not match the current certificate store token value, process 516c returns a response code indicating an error, for example 0306hex (e.g., response code 422).

[0243] Furthermore, returning to question 574, if, for example, sufficient storage is not indicated in the verification certificate extraction block input length 802 to store at least the first requested verification certificate extraction, then none of the requested verification certificate extraction entries will be stored, and process 516c will set the verification certificate extraction block output length 810 to a defined value (e.g., 64) (592); set the stored verification certificate extraction count 814 to, for example, zero (586); and set the remaining verification certificate extraction count 816 to, for example, the count of verification certificate extraction entries that could not be stored (588). Process 516c will return a response code (e.g., response code 422) (590).

[0244] In one or more embodiments, the machine is used to locate, parse, extract, and return extracted verification certificate material based on a specified key type, thereby eliminating the need for each program to duplicate the same locate, parse, and extract code. In one example, fine-grained error detection of one function (subcode 3) is performed by the machine, using another function (subcode 2) to validate the appropriate extractions. In another example, the machine may need to remove invalid verification certificate extractions (holes) whenever they are retrieved from the machine by the hypervisor, compressing the verification certificate extraction storage and renumbering them using different index values ​​for all currently valid verification certificate extractions.

[0245] In one or more embodiments, the program does not need to continuously check for changes in the list of verification certificate extracts for the current configuration, thereby speeding up the checking process and eliminating some coding effort and testing by each software. The hypervisor does not waste processing time building responses that the program would discard in any way. The program has the freedom to retrieve verification certificate extract entries using an entry range that matches its storage management scheme that works best for each software. By using a dynamically updatable certificate store (rather than firmware-embedded certificates), customers can easily update the certificate store with new verification certificate extracts when new certificates become available to verify signed code components. For example, a mechanism is provided to associate and display verification certificates in the certificate store, for example, via a service element panel, using verification certificates retrieved by the software using the verification certificate name and verification certificate index. The program can internally associate verification certificates using, for example, the verification certificate name, key ID, fingerprint, and / or verification certificate index.

[0246] In one example of a diagnostic instruction, a response code is provided for a subcode. For example, a response code of 0001hex indicates that the function was completed successfully; a response code other than 0001hex indicates that the function was not completed successfully.

[0247] In one or more embodiments, an exemplary response code is defined.

[0248] "0001": The specified subcode completed successfully.

[0249] "0102": The specified subcode is not supported.

[0250] "0202": Subcode 1 is specified, but the verification certificate storage size block length field does not store a minimum of, for example, 128.

[0251] "0204": Subcode 2 is specified, but the validation certificate block input length field value is not a multiple of a non-zero value, for example, 4K bytes.

[0252] "0206": Subcode 3 is specified, but the validation certificate extraction block input length field value is not, for example, a non-zero multiple of 4K bytes.

[0253] "0302": Subcode 2 has been specified, but the value of the first verification certificate index is greater than the value of the last verification certificate index.

[0254] "0304": Subcode 3 has been specified, but the value of the first validation certificate extraction index is greater than the value of the last validation certificate extraction index.

[0255] "0306": Subcode 2 or 3 has been specified, but the specified certificate store token value does not match the current certificate store token value in the certificate store for that configuration.

[0256] Additional, fewer, and / or other response codes may be provided. Furthermore, the example values ​​for response codes are merely examples; other values ​​may be provided.

[0257] In one example, diagnosis "0320" may encounter the following program exceptions. In each case, for example, instruction execution is suppressed.

[0258] • A privileged operation exception is recognized when the central processing unit is in a problematic state.

[0259] • A specification exception is recognized if a diagnosis is provided but diagnosis "0320" is not provided.

[0260] For example, a specification exception is recognized if bit positions 0-55 of general-purpose register R3 are not zero.

[0261] A specification exception is recognized if subcodes 0-3 are specified and the R1 field does not specify a register with an even number.

[0262] A specification exception is recognized if subcode 1 is specified and the address specified by general-purpose register R1 is not located on a double-word boundary.

[0263] A specification exception is recognized if subcodes 2-3 are specified and the address specified by general-purpose register R1 is not, for example, located on a 4K byte boundary.

[0264] • As a result of a storage access exception, data is either not provided or incomplete.

[0265] In one example, the resulting condition code remains unchanged.

[0266] Examples of program exceptions include, for instance:

[0267] • Access (Fetch - Subcodes 1-3, Storing - Subcodes 0-3)

[0268] • Privileged operations

[0269] ·specification

[0270] Transaction constraints

[0271] In one or more examples, the verification certificate and its corresponding extracted key have the same index in order to use the same index to match the verification certificate and its corresponding extracted key.

[0272] In one or more examples, the certificate store token may be reinitialized, and the value from the previous IML (initial machine load) may be reused in each new initial machine load.

[0273] In one or more examples, the service element validates the verification key certificate for the entire machine and maintains it in the certificate store. They are indexed, for example, from 1 to N.

[0274] In one or more examples, the service element generates and maintains the extracted key information for a particular key type, such as an elliptic curve key, from the verification key certificate.

[0275] In one or more examples, the hypervisor collects the verification certificates from the certificate store for a given configuration. They are indexed, for example, from 1 to N. However, from the perspective of a given logical partition, a verification certificate with a valid index may not store a valid verification key (i.e., there may be an index that stores an invalid verification key or a hole where the index is not accompanied by any verification certificate information).

[0276] In one or more examples, the hypervisor collects each of these verification certificate extractions (VCX) from the certificate store for a given configuration and separates them by key type. For each extracted key type, the set of verification certificate extractions is also indexed, for example, from 1 to N. However, from the perspective of a given logical partition, a verification certificate extraction with a valid index may not store a valid verification key (i.e., there may be an index that stores an invalid verification key or a hole where the index is not accompanied by any verification certificate extraction information).

[0277] In one or more examples, the bootloader and the operating system are permitted to use different versions of the verification key.

[0278] In one or more examples, the bootloader and the operating system obtain the current verification key from the certificate store for a given configuration when a re-initial program load is executed.

[0279] Other modifications and embodiments are possible.

[0280] Furthermore, while one or more examples of computing environments incorporating and using one or more aspects of the present invention are described herein, Figures 9A and 9B show another embodiment of a computing environment incorporating and using one or more aspects of the present invention.

[0281] Referring first to Figure 9A, in this example, the computing environment 36 includes, for example, a native central processing unit (CPU) 37 based on one architecture having one instruction set architecture, memory 38, and one or more input / output devices and / or interfaces 39, which are coupled to each other via, for example, one or more buses 40 and / or other connections.

[0282] The native central processing unit 37 includes one or more native registers 41, such as one or more general-purpose registers and / or one or more dedicated registers, which are used during processing within the environment. These registers contain information representing the state of the environment at any particular point in time.

[0283] Furthermore, the native central processing unit 37 executes instructions and code stored in memory 38. In one particular example, the central processing unit executes emulator code 42 stored in memory 38. This code enables a computing environment configured in one architecture to emulate another architecture (different from that one architecture) and to execute software and instructions developed based on that other architecture.

[0284] Further details regarding the emulator code 42 are explained with reference to Figure 9B. The guest instructions 43 stored in memory 38 include software instructions (e.g., those correlated with machine instructions) developed to run on architectures other than that of the native CPU 37. For example, the guest instructions 43 may be designed to run on a processor based on another instruction set architecture, but instead are emulated on the native CPU 37, which may be, for example, a single instruction set architecture. In one example, the emulator code 42 includes an instruction fetch routine 44 that retrieves one or more guest instructions 43 from memory 38 and optionally provides local buffering for the retrieved instructions. It also includes an instruction translation routine 45 that determines the type of the retrieved guest instruction and translates the guest instruction into one or more corresponding native instructions 46. This translation includes, for example, identifying the function performed by the guest instruction and selecting the native instruction that performs that function.

[0285] Furthermore, the emulator code 42 includes an emulation control routine 47 that executes native instructions. The emulation control routine 47 may cause the native CPU 37 to execute a native instruction routine that emulates one or more previously obtained guest instructions, and at the end of such execution, return control to an instruction fetch routine that emulates obtaining the next guest instruction or group of guest instructions. Execution of the native instruction 46 may include loading data from memory 38 into registers; returning data from registers to memory and storing it; or performing some type of arithmetic or logical operation as determined by the translation routine.

[0286] Each routine is implemented, for example, in software stored in memory and executed by the native central processing unit 37. In other examples, one or more routines or operations are implemented in firmware, hardware, software, or any combination thereof. The emulated processor registers may be emulated by using the native CPU registers 41 or by using locations in memory 38. In embodiments, the guest instruction 43, native instruction 46, and emulator code 42 may reside in the same memory or may be distributed across different memory devices.

[0287] The exemplary commands that can be emulated are diagnostic commands described herein relating to one or more aspects of the present invention.

[0288] The computing environments described herein are merely examples of computing environments that may be used. One or more embodiments of the present invention may be used with many types of environments. The computing environments provided herein are merely examples. Each computing environment can be configured to include one or more embodiments of the present invention. For example, each may be configured to implement diagnostic and / or initial program loading processes and / or perform one or more other embodiments of the present invention.

[0289] One or more aspects of the present invention are linked to computer technology to facilitate processing within a computer and improve its performance. For example, processing associated with verification certificates is facilitated and processing within the computing environment is improved. Processing related to certificate stores is made more efficient and storage costs are reduced by using a single designed instruction to perform multiple actions for subcodes. Processing within the processor, computer system and / or computing environment is improved.

[0290] In one or more embodiments, the ability is provided to obtain verification information (e.g., public key and key type) for trusted sources for 1 to n keys. The actual keys can be of different types, different lengths, etc. In one or more embodiments, certificates and certificate extractors are provided. The extractors are provided in a more consumable format so that the user does not need to understand how to parse the certificate itself, and instead, it is in a standardized format (for a particular implementation) regardless of the type of certificate.

[0291] In one or more embodiments, current verification information can be obtained at any point in time, meaning that the program will use verification information that is valid at that time, which may be loaded after the initial boot, if one has occurred.

[0292] In one or more embodiments, the certificate store contains certificates and certificate extractors for a specific key type (in one example, no software modules), so there are no predefined pairs of software modules and their corresponding certificates. The program retrieves the current set of verification keys from the certificate store by executing instructions, and uses the retrieved keys one at a time to validate each signed software module.

[0293] In one or more embodiments, multiple keys and information associated with each software module enable the verification of one or more programs, etc., to be loaded into memory. In one or more embodiments, more than one key and its information can be used to verify a single program loaded into memory, and / or multiple programs and any combination thereof.

[0294] Other embodiments, modifications, and / or configurations are possible.

[0295] In addition to the above, one or more aspects may be provided, offered, deployed, managed, serviced, etc. by a service provider that offers to manage a customer environment. For example, a service provider may create, maintain, support, etc. computer code and / or computer infrastructure for executing one or more aspects for one or more customers. In return, the service provider may receive payment from customers under, for example, a subscription and / or fee contract. Additionally or alternatively, the service provider may receive payment from the sale of advertising content to one or more third parties.

[0296] In one aspect, an application may be deployed to execute one or more embodiments. As one example, the deployment of an application includes providing a computer infrastructure operable to execute one or more embodiments.

[0297] As a further aspect, a computing infrastructure may be deployed that includes integrating computer-readable code into a computing system, where the code combined with the computing system is capable of executing one or more embodiments.

[0298] As yet a further aspect, a process for integrating a computing infrastructure that includes integrating computer-readable code into a computer system may be provided. The computer system includes a computer-readable medium, where the computer medium includes one or more embodiments. The code combined with the computer system is capable of executing one or more embodiments.

[0299] Various embodiments are described above, but these are merely examples. For example, other instruction formats, operands, and / or registers may be used. While pages of memory or storage are mentioned, one or more embodiments may be used for other units or sizes of memory or storage. Furthermore, other data units may be specified (for example, bytes are just one example). Moreover, while a hypervisor is described herein as performing a particular embodiment in one or more embodiments, one or more embodiments may be performed by one or more additional and / or other entities, components, etc. Furthermore, material may be extracted for other types of keys. Moreover, other types of certificates may be stored in a certificate store and provided using one or more embodiments of the present invention. Many modifications are possible.

[0300] Various aspects and embodiments are described herein. Furthermore, many modifications are possible without departing from the spirit of the aspects of the present invention. It should be noted that, unless otherwise inconsistent, each aspect or feature described and / or claimed herein, and its variations thereof, may be combined with any other aspect or feature.

[0301] The technical terms used herein are intended solely to describe specific embodiments and are not intended to limit them. Where used herein, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise. Where used herein, the terms "comprises" and / or "comprising" specify the presence of the described features, integers, stages, actions, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, stages, actions, elements, components, and / or groups thereof.

[0302] All means or step-plus-function elements in the following claims are intended to include, in combination with other claimed elements, any structures, materials, or actions for performing a function, if any, specifically claimed. Descriptions of one or more embodiments are presented for illustrative and explanatory purposes, but are not intended to be exhaustive or to limit the disclosed forms. Many modifications and variations will be apparent to those skilled in the art. Embodiments have been selected and described to best illustrate various aspects and practical applications, and to enable other those skilled in the art to understand various embodiments with various modifications suitable for specific uses to be contemplated.

Claims

1. A computer program product for facilitating processing within a computing environment, wherein the computer program product is The method comprises one or more computer-readable storage media, and program instructions collectively stored on the one or more computer-readable storage media for executing the method, The step of obtaining instructions to be executed within the computing environment, the instructions including operational code indicating a diagnostic operation; and The step of executing the aforementioned instruction. The execution has, The step of obtaining a token as input to the aforementioned instruction; A step of comparing the aforementioned token with the current token for configuring the computing environment; and A step of returning one or more verification certificates from the certificate store based on the token that matches the current token. Computer program products, including [this].

2. The computer program product according to claim 1, wherein the returned one or more verification certificates include one or more verification certificates in a scope of verification certificates, the scope of verification certificates is specified using the control block of the instruction.

3. The computer program product according to claim 1, wherein the return step includes storing the one or more verification certificates in a control block specified by the instruction.

4. The instruction is configured to perform a plurality of functions specified by a plurality of subcodes, the instruction is executed based on a selected subcode of the plurality of subcodes, the method further comprises a step of executing another instance of the instruction based on another selected subcode, the step of executing the other instance of the instruction is A step of obtaining the token based on executing the other instance of the instruction; A step of comparing the aforementioned token with the current token for the aforementioned configuration; and A step of returning one or more validation certificates extracted from the certificate store based on the token that matches the current token. A computer program product according to claim 1, including the above.

5. The computer program product according to claim 4, wherein the returned one or more verification certificate extracts include one or more verification certificate extracts in the scope of the verification certificate extracts, the scope of the verification certificate extracts is specified using the control block of the other instance of the instruction.

6. The computer program product according to claim 1, wherein the instruction is configured to perform a plurality of functions specified by a plurality of subcodes, the token has been previously returned as output from a previous execution of the instruction, the previous execution of the instruction is performed based on one of the plurality of subcodes, the previously returned token is provided as input to the instruction being executed, and the instruction is performed based on another of the plurality of subcodes.

7. The computer program product according to claim 6, wherein the preceding execution of the instruction returns storage size information for the configuration, the storage size information is used to determine the amount of storage that will be used to store the one or more verification certificates.

8. The computer program product according to claim 7, wherein the storage size information includes a plurality of storage sizes corresponding to a verification certificate block, and the verification certificate block stores at least one verification certificate from the one or more verification certificates.

9. The computer program product according to claim 8, wherein the plurality of storage sizes include a certificate block length specifying the number of data units in the certificate block having a certificate entry that is the largest certificate entry compared to other certificate entries in the certificate store for the configuration, a total length of the certificate block specifying the total number of data units that will be used to store the certificate block having one or more certificate entries available in the certificate store for the configuration, and a certificate entry length specifying the number of data units for a certificate entry that is the largest certificate entry compared to other certificate entries that will be stored in the certificate store for the configuration.

10. The computer program product according to claim 6, wherein the preceding execution of the instruction returns storage size information for the configuration, the storage size information is used to determine the amount of storage that will be used to store one or more verification certificate extracts, the storage size information includes a plurality of storage sizes corresponding to a verification certificate extract block, the verification certificate extract block stores at least one of the one or more verification certificate extracts.

11. A computer system for facilitating processing within a computing environment, wherein the computer system is memory; and Processor that communicates with the aforementioned memory The computer system is configured to perform a method, and the method is The step of obtaining instructions to be executed within the computing environment, the instructions including operational code indicating a diagnostic operation; and The step of executing the aforementioned instruction. The execution has, The step of obtaining a token as input to the aforementioned instruction; A step of comparing the aforementioned token with the current token for configuring the computing environment; and A step of returning one or more verification certificates from the certificate store based on the token that matches the current token. A computer system, including a computer system.

12. The computer system according to claim 11, wherein the returned one or more verification certificates include one or more verification certificates in a range of verification certificates, the range of verification certificates is specified using a control block of the instruction, and the return step includes storing the one or more verification certificates in the control block specified by the instruction.

13. The instruction is configured to perform a plurality of functions specified by a plurality of subcodes, the instruction is executed based on a selected subcode of the plurality of subcodes, the method further comprises a step of executing another instance of the instruction based on another selected subcode, the step of executing the other instance of the instruction is A step of obtaining the token based on executing the other instance of the instruction; A step of comparing the aforementioned token with the current token for the aforementioned configuration; and A step of returning one or more validation certificates extracted from the certificate store based on the token that matches the current token. The computer system according to claim 11, including the above.

14. The computer system according to claim 11, wherein the instruction is configured to perform a plurality of functions specified by a plurality of subcodes, the token has been previously returned as output from a previous execution of the instruction, the previous execution of the instruction is performed based on one of the plurality of subcodes, the previously returned token is provided as input to the instruction being executed, and the instruction is performed based on another subcode of the plurality of subcodes.

15. The computer system according to claim 14, wherein the preceding execution of the instruction returns storage size information for the configuration, the storage size information being used to determine the amount of storage to be used to store the one or more verification certificates and the amount of storage to be used to store the one or more verification certificate extracts.

16. A computer implementation method that facilitates processing within a computing environment, wherein the computer implementation method is The step of obtaining instructions to be executed within the computing environment, the instructions including operational code indicating a diagnostic operation; and The step of executing the aforementioned instruction. The step of performing the above is, The step of obtaining a token as input to the aforementioned instruction; A step of comparing the aforementioned token with the current token for configuring the computing environment; and A step of returning one or more verification certificates from the certificate store based on the token that matches the current token. A computer implementation method having

17. The computer implementation method according to claim 16, wherein the returned one or more verification certificates include one or more verification certificates in a range of verification certificates, the range of verification certificates is specified using a control block of the instruction, and the return step includes storing the one or more verification certificates in the control block specified by the instruction.

18. The instruction is configured to perform a plurality of functions specified by a plurality of subcodes, the instruction is executed based on a selected subcode of the plurality of subcodes, and the method further comprises a step of executing another instance of the instruction based on another selected subcode, the step of executing the other instance of the instruction is A step of obtaining the token based on executing the other instance of the instruction; A step of comparing the aforementioned token with the current token for the aforementioned configuration; and A step of returning one or more validation certificates extracted from the certificate store based on the token that matches the current token. A computer implementation method according to claim 16, comprising:

19. The computer implementation method according to claim 16, wherein the instruction is configured to perform a plurality of functions specified by a plurality of subcodes, the token has been previously returned as output from a previous execution of the instruction, the previous execution of the instruction is performed based on one of the plurality of subcodes, the previously returned token is provided as input to the instruction being executed, and the instruction is performed based on another subcode of the plurality of subcodes.

20. The computer implementation method according to claim 19, wherein the preceding execution of the instruction returns storage size information for the configuration, the storage size information being used to determine the amount of storage to be used to store the one or more verification certificates and the amount of storage to be used to store the one or more verification certificate extracts.

Images