Diagnosing instructions to perform authentication certificate related functions

Abstract

Instructions to execute in a computing environment are obtained. The instruction includes an opcode indicating a diagnostic operation. The instruction is executed. The execution includes obtaining a token as input to the instruction and comparing the token to a current token of the computing environment for configuration. Based on the token matching the current token, one or more verification certificates are returned from a certificate store.

Description

Background Art

[0001] One or more aspects generally relate to facilitating processing within a computing environment, and more particularly to improving the processing of authentication credentials used during initial program loading within a computing environment.

[0002] In one example of performing an initial program load of software, the software is loaded into, for example, a logical partition. Initial program load is typically a multi-step process in which, for example, firmware on a machine performs the initial program load of some software, such as a boot loader, which in turn loads a main program (typically an operating system), which in turn typically loads additional software packages and programs. Verification that software loaded during the initial program load and later by the software itself is authentic and does not alter what was provided by the software signer is typically performed by authenticating the software using a public key (contained in a certificate (e.g., a verification certificate)) corresponding to the private key used by the software signer to sign the software.

[0003] In this case, the verification key used by both the firmware (to perform the initial program load) and the software may or may not be the same. Furthermore, 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] A computer program product for facilitating processing within a computing environment overcomes the shortcomings of the prior art and provides additional advantages. The computer program product includes one or more computer-readable storage media and program instructions stored collectively on the one or more computer-readable storage media for performing a method. The method includes obtaining an instruction to be executed within the computing environment. The instruction includes an opcode indicating a diagnostic operation. The instruction is executed. The execution includes obtaining a token as input to the instruction and comparing the token to a current token used for configuration of the computing environment. Based on the token matching the current token, one or more verification certificates are returned from a certificate store.

[0005] Computer-implemented methods and systems related to one or more aspects are also described and claimed herein. Additionally, services related to one or more aspects are also 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 a part of the claimed aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] One or more aspects are particularly pointed out and distinctly claimed as examples in the claims at the conclusion of the specification. The foregoing and objects, features, and advantages of one or more aspects will become apparent from the following detailed description taken in conjunction with the accompanying drawings, in which: Figure 1A An example of a computing environment for incorporating and using one or more aspects of the present invention is depicted; Figure 1B Depicts another example of aspects of a computing environment for incorporating and using one or more aspects of the present invention; Figure 2 An example of further details of a processor or processor unit according to one or more aspects of the present invention is described; Figure 3A Described are examples of methods according to one or more aspects of the present invention. Figure 1A An example of a submodule of the diagnostic processing module; Figure 3B Describes an embodiment of the present invention according to one or more aspects Figure 3A An example of the execution instruction submodule; Figure 4A An example of a format for a diagnostic instruction according to one or more aspects of the present invention is described; Figures 4B-4C The invention describes one or more aspects of the Figure 4A an example of fields of a register pair used by an exemplary execution of a diagnostic instruction; Figure 4D The invention describes one or more aspects of the Figure 4A an example of fields of registers used by an example execution of a diagnostic instruction; Figure 5A An example of diagnostic instruction processing according to one or more aspects of the present invention is described; Figure 5B Describes the implementation of one or more aspects of the present invention Figure 5A An example of further details of the functionality; Figure 5C Describes the implementation of one or more aspects of the present invention Figure 5A Another example of further details of the functionality of; Figure 5D Describes the implementation of one or more aspects of the present invention Figure 5A Another example of further details of the functionality of; Figure 6 An example of a storage size block for a verification certificate used in accordance with one or more aspects of the present invention is described; Figure 7AAn example of a verification credential module for use in accordance with one or more aspects of the present invention is described; Figure 7B According to one or more aspects of the present invention, Figure 7A An example of a verification certificate entry of a verification certificate block; Figure 8A An example of a verification certificate extraction module for use in accordance with one or more aspects of the present invention is described; Figure 8B According to one or more aspects of the present invention, Figure 8A An example of a verification certificate extract entry of a verification certificate extract block; Figure 8C An example of an elliptic curve authentication key block for use in accordance with one or more aspects of the present invention is shown; and Figures 9A-9B Another example of a computing environment to incorporate and use one or more aspects of the present invention is shown. DETAILED DESCRIPTION

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

[0009] In one or more aspects, the instructions are configured to include multiple subcodes for multiple functions, and a specific subcode is selected for a specific execution of the instruction. One or more operations based on the selected subcode are performed in the specific execution of the instruction. The instructions can be issued by a program, including but not limited to a boot loader, an operating system, etc. In other embodiments, other programs, entities, and / or components can issue the instructions. Many options and / or variations are possible.

[0010] In one or more aspects, instructions are referred to herein as diagnostic instructions, and processing associated with the instructions, including processing associated with verifying the credentials, is referred to herein as diagnostic processing. The instructions may be used by other programs and / or entities and / or for other purposes. Many variations and options are possible.

[0011] One or more aspects of the present invention are incorporated into, executed by, and / or used by a computing environment. By way of example, the computing environment can be of various architectures and types, including, but not limited to, personal computing, client-server, distributed, virtual, simulated, partitioned, non-partitioned, cloud-based, quantum, grid, time-sharing, clustered, 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, a process (or processes) that performs diagnostic processing (including the execution of selected subcodes that perform diagnostic instructions) and / or one or more other aspects of the present invention. Aspects of the present invention are not limited to a particular architecture or environment.

[0012] Various aspects of the present disclosure are described by narrative text, flow charts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flow chart, depending on the technology involved, the operations may be performed in an order different from the order shown in a given flow chart. For example, two operations shown in successive flow chart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time, again depending on the technology involved.

[0013] Computer program product embodiments ("CPP embodiments" or "CPPs") are terms used in this disclosure to describe any collection of one or more storage media (also referred to as "media") that are collectively included in a collection of one or more storage devices, the collection of one or more storage devices collectively comprising machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. Without limitation, a computer-readable storage medium can be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include magnetic disks, 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 disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punch cards or pits / land formed in a major surface of a disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, should not be construed as storing in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, light pulses through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media. As will be understood by those skilled in the art, data is typically moved at certain occasional points in time during the normal operation of the storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device transitory because the data is not transitory while it is stored.

[0014] refer to Figure 1AAn example of a computing environment for executing, incorporating, and / or using one or more aspects of the present invention is described. In one example, computing environment 100 includes an example of an environment for executing at least some of the computer code involved in executing the methods of the present invention, such as diagnostic processing code or module 150. In addition to block 150, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end-user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, computer 101 includes a processor set 110 (including processing circuitry 120 and cache 121), communication fabric 111, volatile memory 112, permanent storage 113 (including operating system 122 and block 150, as described 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. Remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140 , a cloud orchestration module 141 , a set of host physical machines 142 , a set of virtual machines 143 , and a set of containers 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 now known or developed in the future that is capable of running programs, accessing a network, or querying a database such as remote database 130. As is well known in the art of computer technology, and depending on the technology, the performance of computer-implemented methods may be distributed among multiple computers and / or across multiple locations. On the other hand, in this presentation of computing environment 100, the detailed discussion focuses on a single computer, particularly computer 101, to keep the presentation as simple as possible. Computer 101 may be located in the cloud, although in Figure 1A On the other hand, computer 101 need not be in the cloud unless it can be indicated with certainty to any extent.

[0016] The processor assembly 110 includes one or more computer processors of any type now known or to be developed in the future. The processing circuitry 120 may be distributed across multiple packages, such as multiple cooperating integrated circuit chips. The processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. The cache 121 is a memory located in the processor chip package and is typically used for data or code that should be quickly accessed by the threads or cores running on the processor assembly 110. The cache memory is typically organized into multiple levels based on relative proximity to the processing circuitry. Alternatively, some or all of the caches of the processor assembly may be located "off chip." In some computing environments, the processor assembly 110 may be designed to work with qubits and perform quantum computations.

[0017] Computer-readable program instructions are typically loaded onto the computer 101 to cause the processor assembly 110 of the computer 101 to execute a series of operating steps to implement the computer-implemented method, so that the instructions so executed will instantiate the method specified in the flowchart and / or the narrative description of the computer-implemented method included in this document (collectively referred to as the "inventive method"). 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 the processor assembly 110 to control and direct the execution of the inventive method. In the computing environment 100, at least some of the instructions for performing the inventive method may be stored in block 150 of the permanent storage device 113.

[0018] Communications fabric 111 is the signaling pathway that allows the various components of computer 101 to communicate with each other. Typically, the fabric is comprised of switches and conductive pathways, such as those that constitute a bus, a bridge, physical input / output ports, etc. Other types of signal communication pathways may be used, such as fiber optic communication pathways and / or wireless communication pathways.

[0019] Volatile memory 112 is any type of volatile memory now known or developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory is characterized by random access, but this is not required unless explicitly stated. In computer 101, volatile memory 112 is located in a single package and internal to computer 101, but alternatively or additionally, volatile memory can be distributed across multiple packages and / or located externally relative to computer 101.

[0020] Permanent storage 113 is any form of non-volatile memory for computers that is now known or will be developed in the future. The non-volatility of this memory means that the stored data is maintained regardless of whether power is supplied to the computer 101 and / or directly to the permanent storage 113. Permanent storage 113 can be a read-only memory (ROM), but typically at least a portion of permanent storage allows the writing of data, the deletion of data, and the rewriting of data. Some common forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 122 can take several forms, such as various known proprietary operating systems or operating systems of the open source portable operating system interface type that adopts a kernel. The code included in block 150 is typically included in at least some of the computer code involved in executing the method of the present invention.

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

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

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

[0024] End-user device (EUD) 103 is any computer system used and controlled by an end-user (e.g., a customer of a business operating computer 101), and may take any of the forms discussed above in connection with computer 101. EUD 103 typically receives useful and useful data from the operation of computer 101. For example, in the hypothetical scenario where computer 101 is designed to provide recommendations to an end-user, the recommendations would typically be transmitted from network module 115 of computer 101 to EUD 103 via WAN 102. In this manner, EUD 103 may 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, a heavy client, a mainframe computer, a desktop computer, or the like.

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

[0026] Public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer capabilities, particularly data storage (cloud storage) and computing power, without requiring direct, active management by users. Cloud computing typically leverages resource sharing to achieve consistency and economies of scale. Direct and active management of the computing resources of public cloud 105 is performed by computer hardware and / or software of cloud orchestration module 141. The computing resources provided by public cloud 105 are typically implemented as virtual computing environments running on various computers comprising host physical machine set 142, which is the universe of physical computers in and / or available to public cloud 105. Virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine set 143 and / or containers from container set 144. It should be understood that these VCEs can be stored as images and transferred between various physical machine hosts either as images or after instantiation of the VCEs. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that allows public cloud 105 to communicate over WAN 102 .

[0027] Some further explanation of Virtualized Computing Environments (VCEs) will now be provided. A VCE can be stored as an "image" from which new, active instances of the VCE can be instantiated. Two common types of VCEs are virtual machines and containers. Containers are VCEs that use operating system-level virtualization. This refers to an operating system feature where the kernel allows the existence of multiple isolated userspace instances, called containers. From the perspective of the programs running in them, these isolated userspace instances typically appear to be actual computers. Computer programs running on a normal operating system can make use of all of the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running within a container can only use the contents of the container and the devices assigned to the container, a feature known as containerization.

[0028] 105 . Private cloud 106 is similar to public cloud 105 , except that the computing resources are only available to a single enterprise. Although private cloud 106 is depicted as communicating with WAN 102 , in other embodiments, the private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), typically implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is tied together by standardized or proprietary technologies that enable coordination, management, and / or data / application portability between the multiple constituent clouds. In this embodiment, public cloud 105 and private cloud 106 are both part of a larger hybrid cloud.

[0029] The above-described computing environment is only one example of a computing environment to incorporate, implement, and / or use one or more aspects of the present invention. Other examples are possible. For example, in one or more embodiments, Figure 1A One or more components / modules are not included in the computing environment and / or are not used for one or more aspects of the present invention. In addition, in one or more embodiments, additional and / or other components / modules can be used. Other variations are possible.

[0030] refer to Figure 1B Another example of aspects of a computing environment for incorporating, using, and / or performing one or more aspects of the present invention is described. In one example, a computing environment 160 supports logical partitioning and includes, for example, a memory 165 (also referred to as system memory, main memory, primary storage, central storage, storage; for example, persistent storage such as persistent storage 113; other storage, etc.) coupled to one or more processor units 190 (e.g., central processing units (CPUs), other types of processors, etc.) of, for example, a processor set (e.g., processor set 110).

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

[0032] Logical partition support provides the ability to operate a large number of logical partitions 170, each capable of operating with a different program 180 and running a guest operating system 182. Each logical partition 170 can function as a separate system. That is, each logical partition can be independently reset, run a guest operating system, and operate with different programs. An operating system or application running in a logical partition appears to have access to the entire system, but in reality, only a portion of the system is available.

[0033] In one example, logical partition 170 includes one or more logical processors, each of which represents all or a portion of a physical processor resource (eg, processor unit 190 ) that can be dynamically allocated to the logical partition.

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

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

[0036] The program loaded or otherwise launched by the initial program executes instructions to perform operations within the computing environment. To execute the instructions, in one example, functional components such as a processor unit or processor (e.g., of the processor assembly 110) are used. Figure 2An example of functional components for executing instructions is described. In one example, the functional components for executing instructions include, for example, an instruction fetch component 200 for fetching instructions to be executed; an instruction decode / operand fetch component 202 for decoding the fetched instructions and obtaining operands for the decoded instructions; one or more instruction execution components 204 for executing the decoded instructions; a memory access component 206 for accessing memory as necessary for instruction execution; and a writeback component 208 for providing results of the executed instructions. One or more components may access and / or use one or more registers 210 in instruction processing. Additionally, one or more components may access and / or use diagnostic processing module 150. Additional, fewer, and / or other components may be used in one or more aspects of the present invention.

[0037] According to one or more aspects of the present invention, the diagnostic processing module (e.g., diagnostic processing module 150) includes a code or instruction for performing diagnostic processing. In one example, the diagnostic processing module (e.g., diagnostic processing module 150) includes various submodules for performing processing. A submodule is a computer-readable program code (e.g., instruction) in, for example, a computer-readable medium, and the computer-readable medium is, for example, a storage device (e.g., storage device 124, permanent storage device 113, cache 121, other storage devices). The computer-readable medium can be part of a computer program product, and the computer-readable program code can be executed and / or used to execute by one or more computing devices (e.g., one or more computers, such as computer 101; one or more servers, such as remote server 104; one or more processors, such as a processor unit or processor of processor set 110; a processing circuit, such as the processing circuit 120 of processor set 110; and / or other computing devices, etc.). In addition, fewer and / or other computers, servers, processors, processor units, processing circuits, and / or computing devices can be used to execute one or more of the submodules and / or their parts. Many examples are possible.

[0038] Reference Figure 3A An example of the diagnostic processing module 150 is described. In one example, the diagnostic processing module 150 includes an obtain instruction submodule 300 for obtaining (e.g., receiving, being provided, pulling, retrieving, acquiring, being issued, etc.) diagnostic instructions to be executed, and an execute instruction submodule 310 for executing the diagnostic instructions.

[0039] In one example, reference Figure 3BThe execute instruction submodule 310 includes, for example, an operand acquisition submodule 312 for acquiring one or more operands of the diagnostic instruction; a function determination submodule 314 for determining a function to be performed by the diagnostic instruction; and an execute function submodule 316 for executing the determined function. Furthermore, fewer and / or additional submodules may be used to implement diagnostic processing, including executing diagnostic instructions and / or other processing associated therewith.

[0040] Reference Figure 4A An example of a diagnostic instruction is described. In one embodiment, a diagnostic instruction such as diagnostic instruction 400 (also referred to as diagnostic '0320' in a particular architecture) is a hardware machine instruction for a single architecture at the hardware / software interface. It is configured to include multiple subcodes, and a specific subcode is indicated in the instruction call. The execution of each subcode includes performing one or more operations as part of the execution of the diagnostic instruction for the specified subcode.

[0041] As an example, in one implementation, the diagnostic instructions are part of an instruction set architecture. An example of an instruction set architecture for incorporating and / or using diagnostic instructions and / or aspects of the present invention is provided by International Business Machines Corporation of Armonk, New York. Instruction Set Architecture. 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 incorporated herein by reference in its entirety. However, the z / Architecture instruction set architecture is merely one example 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.

[0042] In one example, the diagnostic instruction 400 has a format called a register and, for example, a 32-bit storage operand format. In this particular example, the diagnostic instruction 400 has an opcode (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 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 used in the execution of the diagnostic instruction; a base register field (e.g., B2) 408 (e.g., bits 16-19) that specifies a base register; and a displacement (e.g., D2) field 410 (e.g., bits 20-31) that specifies a displacement value that is added to the value in the base register specified in the base register field 408 to provide a value to be used as the opcode extension of the diagnostic instruction 400. Each field is described below.

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

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

[0045] In one example, before invoking diagnostic '0320', the operating system may "pin" the memory region addressed by the contents of general register R1 to prevent invalid translations caused by memory management on another processor. In one example, if virtual addressing is used, the diagnostic '0320' instruction performs dynamic address translation before accessing the page, but subsequent stores to the page are not interlocked with invalid page table entries from other processors. Therefore, diagnostic instructions can continue to be stored into the page frame even after memory management on another processor has reallocated the diagnostic instruction.

[0046] In one example, reference Figure 4C , a response code 422 is returned in, for example, bit positions 48-63 of the contents 404b of general register R1+1. As an example, a response code of {0001} hexadecimal indicates that the operation completed successfully, while a response code of {0102} hexadecimal indicates that the subcode is not supported on this model. Other response codes / response code values ​​are also possible.

[0047] Furthermore, in one example, reference Figure 4D The contents 406a of general register R3 (e.g., bits 56-63) include a subcode 432 (e.g., an 8-bit unsigned integer) that identifies the specific function to be performed by the diagnostic instruction. Examples of subcodes include, for example, subcode 0—query installed subcodes for determining subcodes supported by the diagnostic '0320'; subcode 1—query verification certificate storage information; subcode 2—store verification certificate; and subcode 3—store verification certificate extract. Additional, fewer, and / or other subcodes may be provided.

[0048] In one embodiment, the fields of the instruction are separate and independent of each other; however, in other embodiments, more than one field can be combined. In addition, the field can be extended to more than one position. For example, a field can be in a bit set and extend to another bit set separated from the one bit set (for example, at the beginning of the instruction format and at the end of the instruction format; and / or its variants). Although example types of registers are specified, other types of registers can be used. In addition, although example positions in the instruction format are provided, other positions can be used for one or more of the instruction fields. Diagnostic instructions such as diagnostic instruction 400 can have additional, fewer and / or other fields. Other examples are possible.

[0049] In addition, in the description of diagnostic instructions such as diagnostic instruction 400 herein, the specific size (for example, specific byte and / or bit) of a specific location, specific field and / or field can be indicated. However, other locations, fields and / or sizes can be provided. In addition, although it is possible to specify that a bit is set to a specific value, for example one or zero, this is only an example. In other instances, if the position is provided, it can be set to different values, for example opposite value or another value, so. Many variations are possible.

[0050] If a field has a subscript number associated with it, the subscript number associated with the field indicates the operand to which the field applies. For example, the subscript number 1 associated with register R1 indicates that the register(s) designated by R1 comprise the first operand, the subscript number 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 opcode extension (e.g., '0320' hexadecimal)) provides various functions associated with a certificate store (CS) facility. For example, it obtains current verification certificate information for a requesting configuration (e.g., for a guest such as a guest operating system (e.g., guest operating system 182) and / or other guests) from a certificate store (e.g., certificate store 185) and returns the certificate information to the program. The verification certificates are validated before being placed in the certificate store.

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

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

[0054] In one example, the verification certificates for a given configuration are stored in a verification certificate block (VCB). In one example, they are indexed from one to N. However, not every verification certificate in the index list necessarily contains a valid certificate (i.e., there may be index entries that are not marked as valid).

[0055] In one example, the certificate store also maintains specific material, such as elliptic curve keys, extracted from the verification certificate for a specific key type. The collection of extracted key type material for the verification certificate is called a verification certificate extract (VCX). In one example, the verification certificate extracts are stored separately in a verification certificate extract module (VCXB). (In other examples, they can be stored with the verification certificate, and there are various possibilities.) In one example, the verification certificate extracts for a configuration are indexed from one to N; for a configuration, the index of the verification certificate extract is the same as the index of the verification certificate from which the specific material was extracted. That is, the VCX X Corresponding to VC X However, not every verification certificate extract in the index list may contain a valid verification key (ie, there may be index entries that do not contain a valid verification key).

[0056] In one example, verification certificates and verification certificate extracts maintained in a certificate store are obtained and stored by executing instructions such as diagnostic '320.' Deleted or expired verification certificates are indicated as invalid verification certificates in their corresponding control block entries. In one example, when a verification certificate is invalid, its corresponding verification certificate extract is also invalid.

[0057] When a verification certificate is valid and includes a key of a key type that supports the verification certificate extract format, then the corresponding verification certificate extract is also valid.Thus, a valid verification certificate may not imply a valid verification certificate extract.

[0058] In one example, a certificate store (CS) token value is used to represent the current version of the list of verification certificates and their corresponding verification certificate extracts that are available in the certificate store for the configuration (e.g., for a guest, such as a guest operating system (e.g., guest operating system 182) and / or other guests). The value in this field will change when changes occur within the certificate store for the configuration. For example, the value is updated whenever one or more verification certificates and their corresponding verification certificate extracts are added, deleted, or modified.

[0059] In one example, the certificate store token value is not updated when executing a certificate store function. In one example, the list of verification certificates and the corresponding list of verification certificate extracts in the certificate store for a configuration are not added, deleted, or modified until the currently running diagnostic '0320' function completes. Similarly, while verification certificates and corresponding verification certificate extracts are updated for a configuration, subsequent diagnostic '0320' functions will not be initiated.

[0060] In one example, a credential storage token value is not reused until every credential storage token value has been used.Other variations are possible.

[0061] Furthermore, in one example, the program (e.g., boot loader, operating system) ensures that upon discovering that the certificate store token value has changed for a configuration, the relevant information obtained from the certificate store for any previous configuration is re-evaluated. This includes the maximum and maximum values ​​described herein. Furthermore, in one example, the index of the certificate store has a single source. A request that includes a certificate with an index of zero provides an indication that no certificate is available for that index.

[0062] As noted, in one embodiment, according to one or more aspects of the present invention, the diagnostic instructions implement multiple subcodes, three of which are described herein. These subcodes are referred to, for example, as Subcode 1 - Query Verification Certificate Stored Information; Subcode 2 - Store Verification Certificate; and Subcode 3 - Store Verification Certificate Extract; however, they may be referred to in other ways. Each subcode is further described below.

[0063] Subcode 1 Query verification certificate storage information

[0064] In one or more aspects, a program (e.g., a boot loader, an operating system, another program, etc.) may use diagnostic '0320' subcode 1 to obtain certificate store information to find a current version number of a certificate store for a current configuration and determine an amount of storage from the certificate store for the current configuration for storing one or more verification certificates (VCs) and / or their corresponding verification certificate extracts (VCXs).

[0065] In one embodiment, subcode 1 returns various storage sizes specific to, for example, a verification certificate block (VCB) and a verification certificate extract block (VCXB).

[0066] If no verification certificate exists for the configuration, the verification certificate storage size block (VCSB) length is set to a defined value, eg, 4, and a response code 422, eg, 0001 hexadecimal, is returned in, eg, bit positions 48-63 of general register R1+1.

[0067] In one example, when the Certificate Store (CS) facility is installed in a particular architecture and architecture mode (e.g., the z / architecture instruction set architecture in architecture mode), diagnostic '0320' subcode 1 is valid. For other architectures, this check may not be performed, and / or other architectures may perform other checks. There are many possibilities.

[0068] In one example, the first operand will be specified on a doubleword boundary; otherwise, in one example, a specification exception is recognized. In addition, in one example, the output data returned by the diagnostic '0320' subcode 1 when the operation completes successfully is stored, for example, in a verification certificate storage size block (VCSB), an example of which is described below.

[0069] In operation, in one example, subcode 1 (i.e., execution of diagnostic instruction 400 with, for example, subcode 432 set to 1) obtains certificate store information to find a current version number of the certificate store and determines from the certificate store an amount of storage for the current configuration for storing one or more verification certificates and / or their corresponding certificate store extracts.

[0070] In one example, it obtains a consistent set of information regarding how many verification certificates and / or verification certificate extracts will be provided by subsequent issuances of the diagnostic '0320' instruction, as well as storage requirements, so as to retrieve these certificate materials all at once or in one or more increments at a time (to save memory requirements) at the discretion of the program.

[0071] In one example, diagnostic '0320' subcode 1 returns information to accommodate different operating system implementations by providing, for example, a maximum single verification certificate block / verification certificate extract block length to determine a minimum number of data units (e.g., bytes) to obtain a verification certificate block / verification certificate extract block having at least one verification certificate block / verification certificate extract block entry available in a certificate store for the current configuration; providing, for example, a total verification certificate block / verification certificate extract block length for the current configuration to determine a minimum number of bytes to use to obtain a verification certificate block / verification certificate extract block having all verification certificate block / verification certificate extract block entries available in a certificate store for the current configuration; and / or providing, for example, a number of bytes to contain a maximum number of verification certificate entries / verification certificate extract entries supported by the current machine model on which the software is running. For example, the maximum number of verification certificate entries / verification certificate extract entries supported by the current model of the central electronic complex (CEC) that includes the logical partition on which the software is executing is provided.

[0072] In one or more aspects, the hypervisor ensures that the program does not view updated results when collecting the authentication certificate list and / or authentication certificate extract list for the current configuration across multiple issuances of the diagnostic '0320' instruction. As an example, the operating system does not have to check the returned information for consistency across these multiple issuances; any information that is successfully returned comprises a consistent set of information.

[0073] According to one or more aspects of the present invention, a diagnostic process is used to perform diagnostic processing, including executing diagnostic instructions, such as diagnostic instructions 400. Figures 5A-5D An example of such processing is described. In one example, a diagnostic process (e.g., diagnostic process 500) can be implemented using one or more submodules (e.g., one or more of submodules 300-316) and performed 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 group 110 or other processor groups), and / or other computing devices, etc.). Although example 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 can be used for the diagnostic process and / or other processing. Various options are possible.

[0074] refer to Figure 5AIn one example, a diagnostic process 500 obtains 502 (e.g., receives, retrieves, extracts, is provided, pulled, issued, etc.) an instruction, such as diagnostic instruction 400. For example, in one example, a program (e.g., a boot loader or operating system) issues a diagnostic '0320' instruction specifying subcode 1 (query verification certificate storage information) to obtain specific storage information for the current configuration to determine the amount of storage to be used for storing one or more verification certificates and / or their corresponding verification certificate extracts in the certificate store for the current configuration. These data blocks are used, for example, to verify a signed load module (binary code). Based on the instruction issued by the program, process 500 obtains the instruction and executes 510 the instruction, for example, via a hypervisor (e.g., hypervisor 172). Execution includes, for example, obtaining 512 one or more operands of the instruction. By way of example, process 500 obtains one or more of: an opcode using opcode field 402, a subcode 432 using R3 field 406, and a first operand address 420 using R1 field 404. In one or more embodiments, additional, fewer, and / or other operands may be used. Many variations are possible.

[0075] In one example, based on the obtained operands, process 500 determines 514 a function to be performed (e.g., as specified, for example, by subcode 432). In one example, the function is the query verification certificate storage information function specified by subcode 1. However, additional, fewer, and / or other functions may be specified. Furthermore, in other embodiments, no subcode is specified, and the function is determined from another field of the instruction, such as one or more opcode fields, one or more other fields, or by implication, etc. Many variations are possible.

[0076] In one example, based on determining the function, process 500 performs 516 the function. As an example, a hypervisor (e.g., hypervisor 172) performs the function, including one or more operations of the function. In other examples, other entities, components, etc. may perform one or more functions and / or one or more operations of a function. Many variations are possible.

[0077] refer to Figure 5B Further details regarding one example of performing this function (eg, querying verification certificate storage information—subcode 1) are described.

[0078] In one embodiment, process 516a performs a query to obtain storage information to be used to determine the amount of storage to be used for storing one or more verification certificates and / or corresponding verification certificate extracts. Process 516a determines 520 whether any verification certificates for the requested configuration exist in the certificate storage unit, for example. If one or more verification certificates for the requested configuration exist in the certificate storage unit, storage size information to be provided is determined 522 for determining the amount of storage to be used for storing 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 information or control blocks, such as the verification certificate storage size block, referenced Figure 6 Examples thereof are described. For example, a count of available verification certificates in the certificate store for the configuration, the maximum possible number of bytes of a verification certificate entry that can be stored in the certificate store for the configuration, and the maximum possible number of bytes of a verification certificate extract entry that can be stored in the certificate store for the configuration are provided. Additional, lesser, and / or other storage size information may be provided.

[0080] refer to Figure 6 Describing an example of a verification certificate storage size block, in one example, a verification certificate storage size block (VCSB) 600 includes:

[0081] Verification Certificate Storage Size Block Length 602: This field (e.g., word 0) includes, for example, 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 will be set by the program to a minimum value, e.g., 128; otherwise, a response code 422, e.g., 0202 hexadecimal, is returned in, e.g., bit positions 48-63 of general register R1+1. If no verification certificate exists for this configuration, the Verification Certificate Storage Size Block Length is set by the machine (e.g., hypervisor) to a defined value, e.g., 4, and a response code 422, e.g., 0001 hexadecimal, is returned in, e.g., bit positions 48-63 of general register R1+1. Other response codes / response code values ​​are possible.

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

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

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

[0085] Total Verification 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 verification certificates available in the certificate store for this configuration. In one example, the count includes the available verification certificate index, regardless of the validity status of the included verification certificates.

[0086] Maximum Verification Certificate Count 610: This field (eg, bytes 2-3 of word 8) contains an unsigned binary integer (eg, 16 bits) that specifies the maximum count of verification certificates that can be stored in the certificate store for this configuration.

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

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

[0089] Maximum Single Verification Certificate Block Length 616: This field (eg, word 20) contains an unsigned binary integer (eg, 32 bits) that specifies the number of bytes in the verification certificate block with the largest single verification certificate entry currently available in the certificate store for this configuration.

[0090] Total Verification Certificate Block Length 618: This field (e.g., word 21) includes an unsigned binary integer (e.g., 32 bits) that specifies the total number of bytes to be used to store the verification certificate blocks with the verification certificate block entries currently available in the certificate store for this configuration.

[0091] Maximum Single Verification Certificate Extract Block Length 620: This field (e.g., word 22) contains an unsigned binary integer (e.g., 32 bits) that specifies the number of bytes in the verification certificate extract block that has the largest single verification certificate extract entry currently available in the certificate store for this configuration.

[0092] Total Verify Certificate Extract Block Length 622: This field (e.g., word 23) includes an unsigned binary integer (e.g., 32 bits) that specifies the total number of bytes in the Verify Certificate Extract Block that has the current Verify Certificate Extract Block entry in the certificate store for this configuration.

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

[0094] Back to Figure 5B Based on the size information (or another information or control block) stored in the verify certificate storage size block 600, process 516a returns 526 to the verify certificate storage size block, assuming subcode 1 completed successfully. Furthermore, in one example, process 516a returns 528 response code 422 in, for example, register R1+1. For example, if the subcode completed successfully, a response code of '0001' hexadecimal is returned. Other response codes may also be returned, examples of which are described herein.

[0095] Returning to query 520, if it is determined that the verification certificate does not exist in the certificate store, process 516a sets the verification certificate storage size block length 602 to a defined value, such as 4. Furthermore, in one example, process 516a returns 528 a response code 422 in, for example, register R1+1. For example, a response code of '0001' hexadecimal may be returned. Other response codes may also be returned.

[0096] In one or more aspects, the diagnostic '0320' instruction provides a mechanism to obtain a verification certificate and / or verification certificate extract 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 that represents the current version of the certificate store for the current configuration. The program saves the returned certificate store token value and provides it as an input certificate store token value to other functions (e.g., subcodes 2 and 3). In one example, if the current certificate store token is different from the input certificate store value used for other functions, the hypervisor returns a certificate store token error response code. If the hypervisor returns a certificate store token error response code, the program restarts the above process to obtain the corresponding control block again to ensure that the certificate store token value is consistent with the corresponding control block it obtained from the certificate store for the current configuration. This mechanism allows the hypervisor to ensure that the verification certificate list and / or verification certificate extract list for the configuration does not change when they are retrieved asynchronously using subsequent and different diagnostic '0320' functions.

[0097] In one or more aspects, the hypervisor serializes the execution of the diagnostic '0320' instruction and the certificate store update so that the current certificate store token value does not change due to a change in the certificate store for the current configuration until all ongoing instances of the diagnostic '0320' instruction have completed execution. In one example, a certificate store token value is not reused until every possible certificate store token value has been used to prevent software (e.g., a program) from seeing the same certificate store token value for two different certificate store versions. This process ensures that the program does not view the results of the update when it asynchronously collects the verification certificate list and / or verification certificate extract list for the current configuration in, for example, a scatter-gather list by issuing multiple instances of the diagnostic '0320' instruction.

[0098] In one or more aspects, the diagnostic '0320' instruction returns various storage sizes specific to the verification certificate block and the verification certificate extract block, including, by way of example, the following:

[0099]

[0100]

[0101]

[0102]

[0103]

[0104]

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

[0106] In one or more aspects, the program does not have to continually check for changes in the list of verification certificates and / or the list of verification certificate extracts for the current configuration, which speeds up and simplifies the checking process and eliminates some coding work and testing for each operating system. The hypervisor does not have to waste time formulating and returning data that will be discarded by the program, which reduces execution time. The operating system has the freedom to choose one of multiple storage management schemes that does the best job for each operating system to manage its memory. The use of a dynamically updateable certificate store (rather than firmware embedded certificates) allows customers to easily update the certificate store with new verification certificates as new certificates become available and will be used to verify signed code components.

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

[0108] Subcode 2 – Storage Verification Certificate

[0109] In one or more aspects, a program (e.g., a boot loader, an operating system, another program, etc.) can use diagnostic '0320' subcode 2 to directly obtain a verification certificate (which contains a verification key). Subcode 2 is used to look up one or more verification certificates and certain verification certificate-related information currently 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 function is valid when the certificate storage facility is installed in a specific architecture and architecture mode (e.g., the z / Architecture instruction set architecture in architecture mode). For other architectures, this check may not be performed, and / or other architectures may perform other checks. There are many possibilities.

[0111] In one example, a logical address of a verification certificate block (VCB) is generated under control of the current addressing mode. The logical address will be specified, for example, on a 4K byte boundary; otherwise, in one example, a specification exception is recognized. A verification certificate block, examples of which are described below, can be, for example, a multiple of 4K bytes in length. The length of the verification certificate block is specified, for example, in multiples of 4K bytes, by a verification certificate block input length field, such as word 0 of the verification certificate block.

[0112] The Verification Certificate Block comprises, for example, output data returned by the diagnostic '0320' subcode 2 when the operation completes successfully. It comprises, for example, a common header followed by, for example, zero or more Verification Certificate Entries (VCEs).

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

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

[0115] In one example, when insufficient storage space is provided in the verification certificate module input length field to store at least the first requested verification certificate entry, the requested verification certificate entry is not stored, and the verification certificate module output length (in the verification certificate module) is set to a defined value, such as 64. The stored verification certificate count is set to, for example, zero, the remaining verification certificate count is set to, for example, the count of verification certificate entries that could not be stored in the verification certificate module, and a response code 422, such as 0001 hexadecimal, is returned, such as in bit positions 48-63 of general register R1+1.

[0116] In one example, when insufficient storage space is provided in the verification certificate module input length field to store the requested verification certificate entries, the maximum number of verification certificate entries that can fit in the verification certificate module is stored in a stored verification certificate count (SVCC) of the verification certificate module, and a count of the verification certificate entries that cannot be stored in the verification certificate module is stored in a remaining verification certificate count (RVCC) field of the verification certificate module.

[0117] In operation, in one example, subcode 2 (i.e., execution of the diagnostic instruction 400 with subcode 432 set to 2, for example) is used by, for example, a program to directly obtain a verification certificate (which contains a verification key). Subcode 2 is used to look up one or more verification certificates and certain verification certificate-related information currently in the certificate store for the current configuration. In one example, the program specifies the first and last verification certificates it desires, as well as a certificate store token, and subcode 2 provides a verification certificate block output length corresponding to the amount of memory available for the program, which, for example, firmware can use to return certificates (if any) from a specified range.

[0118] In one example, the diagnostic '0320' instruction, subcode 1 (Query Verification Certificate Storage Information) previously returned the number of verification certificates in the machine's public verification certificate store, and in one example, the index from the first verification certificate to the last verification certificate had no gaps. Thus, the designation of the first and last verification certificates allows the requesting program to obtain the verification certificate it desires, as long as the certificate fits within the memory provided to, for example, the firmware. If desired, the program can repeatedly issue the diagnostic '0320' subcode 2 instruction to eventually cause the firmware to return all verification certificates in its public certificate store, for example, for the currently configured machine.

[0119] The provided certificate store token (e.g., as output of subcode 1 and used as input to subcode 2) must match the current certificate token. In one example, if the provided certificate store token does not match the current value, an error is returned. This thus provides a simple technique for ensuring that the authentication credentials in the public certificate store in the machine have not changed since the diagnostic '0320' instruction subcode 1 was issued, including any previous diagnostic '0320' instruction subcode 2 operations that were also issued.

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

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

[0122] In one or more aspects, a program (e.g., a boot loader, an operating system, etc.) issues a diagnostic '0320' instruction that specifies subcode 2, a validation certificate entry range, and a certificate store token to obtain one or more validation certificates in a certificate store for a current configuration. In one example, if the current certificate store token for the certificate store for the current configuration is different than the specified certificate store token value, the hypervisor returns an error. This mechanism allows the hypervisor to ensure that the list of validation certificates for the configuration does not change when the function is used to retrieve them, and that subsequent diagnostic '0320' functions will run asynchronously against the same certificate store version (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 / saved certificate store token value (obtained from diagnostic '0320' subcode 1) to determine if one or more validation certificates have changed.

[0123] In one aspect, the diagnostic '0320' instruction returns one or more verification certificates based on a range of verification certificate entries in a certificate store for a current configuration. The one or more verification certificates are returned in a verification certificate block that 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 that determine a range of verification certificates to be stored by a store verification certificate function; and a count of verification certificate entries (VCEs) stored in the verification certificate block. In one example, when insufficient storage space is provided in the verification certificate module input length field to store the requested verification certificate entries, a count of the verification certificate entries that cannot be stored in the verification certificate module is stored in a remaining verification certificate count (RVCC) field.

[0124] Each verification certificate block entry includes information such as one verification certificate.

[0125] refer to Figures 7A-7B Further details related to the verification certificate block and verification certificate entries are described. In one example, the verification certificate block 700 ( Figure 7A ) includes a common header (e.g., 16 words) followed by zero or more verification certificate entries (VCEs). In one example, selected positions (e.g., words 0-7) of the common header include input data, while other selected positions (e.g., words 8-15) of the common header include output data. In one example, subcode 2 stores a list of verification certificates in certificate format within a verification certificate block.

[0126] In one example, the 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) that specifies the number of bytes in the verification certificate block. In one example, this value will be a non-zero multiple of, for example, 4K; otherwise, a response code 422, such as 0204 hexadecimal, is returned in, for example, bit positions 48-63 of general register R1+1.

[0128] First Verification 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 verification certificate in the certificate store to be stored in the first verification certificate entry. In one example, this value is less than or equal to the value of the last verification certificate index; otherwise, a response code 422, e.g., 0302 hexadecimal, is returned in, for example, bit positions 48-63 of general register R1+1.

[0129] Last Verification Certificate Index 706: This field (eg, bytes 2-3 of word 2) contains an unsigned binary integer (eg, 16 bits) that specifies the index of the verification certificate in the certificate store that is to be stored in the last verification certificate entry.

[0130] In one example, a value of zero is a valid index for the first and / or last verified certificate index for this instruction. However, because the certificate store maintains a single source of indexes, no certificate with an index value of zero is available. A request for a single certificate with an index of zero results in zero certificates being returned. A request for multiple certificates starting at zero results in the first returned certificate entry containing certificate index one.

[0131] Certificate Store (CS) Token 708: This field (e.g., word 4) contains an unsigned binary integer (e.g., 32 bits) that specifies the version of the verification certificate to 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 this configuration, a response code 422, e.g., 0306 hexadecimal, is returned in, e.g., bit positions 48-63 of general 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 when the operation completes successfully. In one example, this value is greater than or equal to, for example, 64.

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

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

[0135] Remaining Verification Certificates Count 716: This field (eg, bytes 2-3 of word 10) contains an unsigned integer (eg, 16 bits) that is a count of the verification certificates that could not be stored in the verification certificate block due to insufficient storage specified in the Verification Certificate Block Input Length field.

[0136] Verification Certificate Entries 718: In one example, the verification certificate block (e.g., words 16 through N) can contain zero or more verification certificate entries based on the verification certificate block input length and the verification certificate range (e.g., from first verification certificate index to last verification certificate index) currently in the certificate store for this configuration. In one example, the verification certificate entries have a common header followed by the verification certificate in certificate format.

[0137] In one example, each verification certificate entry is aligned, for example, word-aligned. Each variable-length field within a verification certificate entry is also aligned, for example, word-aligned. In one example, a verification certificate entry length that is, for example, a multiple of four is used to form gaps between verification certificate entries, and a verification certificate entry field offset that is, for example, a multiple of four is used to form gaps between verification certificate entry fields to provide, for example, word boundary alignment. The verification certificate entry field length includes a value that is, for example, the actual size of the verification certificate entry field, and unused areas (gaps) after the verification certificate entry field contain, for example, zeros.

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

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

[0140] Verification Certificate Entry Length 730: This field (eg, word 0) contains an unsigned binary integer (eg, 32 bits) that specifies the number of bytes in the entire verification certificate entry. The verification certificate entry length field value is, for example, a multiple of 4 bytes.

[0141] Verify Certificate Entry Flags 732: In one example, this field (e.g., byte 0 of word 1) includes a Flags field defined as follows: Bit meaning 0 Verify certificate validity (VCV): When bit 0 is, for example, one: When the bit is, for example, zero: 1-7 Reserved

[0142] Key Type 734: This field (eg, byte 1 of word 1) includes an unsigned binary integer (eg, 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] In one example, the key type field value is defined as follows: Value meaning 0 Unsupported key type 1 ECDSA (Elliptic Curve Digital Signature Algorithm) – NIST (National Institute of Standards and Technology) curve P521 2-255 Reserved

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

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

[0146] Verification 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 verification certificate. In one example, the Verification Certificate Format field value is defined as follows: Value meaning 0 Unsupported authentication certificate format X.509 certificate in DER (Distinguished Encoding Rules) format. 2-255 Reserved

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

[0148] Verification 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 (also known as the fingerprint) used to identify the verification hash of the verification certificate. In one example, the Verification Certificate Hash Type field value is defined as follows: Bit meaning 0 Unsupported authentication certificate hash type 1 SHA2-256 (Secure Hash Algorithm) 2-255 Reserved

[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) that specifies the number of bytes in the Verification Certificate Hash field. The Verification Certificate Hash Length field value is, for example, a multiple of 1 byte.

[0150] Verification Certificate Length 748: This field (eg, word 21) contains an unsigned binary integer (eg, 32 bits) that specifies the number of bytes in the Verification Certificate field. The Verification Certificate Length field value is, for example, a multiple of 1 byte.

[0151] Verification Certificate Hash Offset 750: This field (eg, bytes 0-1 of word 24) contains an unsigned binary integer (eg, 16 bits) that specifies the Verification Certificate Hash Offset field. The Verification Certificate Hash Offset field value is, for example, a multiple of 4 bytes.

[0152] Verification Certificate Offset 752: This field (eg, bytes 2-3 of word 24) contains an unsigned binary integer (eg, 16 bits) that specifies the offset of the Verification Certificate field. The Verification Certificate Offset field value is, for example, a multiple of 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, for example, word-aligned.

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

[0155] Verification Certificate 758: This field (eg, word B+1-N) includes 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 aspects, a hypervisor and a program cooperate to ensure that the program asynchronously obtains the entire verification certificate list 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 a portion of the verification certificate list is being collected by issuing multiple instances of a 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 constructing a response that the program would discard and restart the verification 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 scope and returns it in the verification certificate format with the verification certificate entry. Figure 5A and 5C The return of the verification certificate is further described.

[0158] In one example, reference Figure 5A Based on the determination 514 that the diagnostic '0320' subcode 2 function is to be performed, the process 500 performs 516 the function. Figure 5C Further details related to performing the function of storing the verification certificate (subcode 2) are described.

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

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

[0161] The process 516b determines 552 whether there is sufficient storage space to store the requested verification certificate entries in the verification certificate block. If there is insufficient storage space to store the verification certificate entries in the requested verification certificate block, in one example, the process 516b sets 556 a stored verification certificate count (e.g., count 714) in the verification certificate block to the number of entries stored in the verification certificate block and sets 558 a remaining verification certificate count (e.g., count 716) in the verification certificate block to the number of requested entries that cannot be stored.

[0162] In one example, process 516b returns 560 a response code such as 0001 hexadecimal (eg, response code 422).

[0163] Returning to query 552, in one example if there is sufficient storage space to store the requested verification certificate, process 516b returns 560 a response code, such as 0001 hexadecimal (eg, response code 422).

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

[0165] Additionally, returning to query 543, if the provided credential store token value does not match the current credential store token value, process 516b returns a response code, such as 0306 hexadecimal (eg, response code 422), indicating an error.

[0166] Furthermore, returning to query 544, if, for example, the verification certificate block input length 702 does not indicate sufficient storage space to store at least the first requested verification certificate, then the requested verification certificate entry is not stored, and the process 516b sets 562 the verification certificate block output length 710 to a defined value (e.g., 64); sets 556 the stored verification certificate count 714 to, for example, zero; and sets 558 the remaining verification certificate count 716 to, for example, the count of verification certificate entries that could not be stored. The process 516b returns 560 a response code, for example, 0001 hexadecimal (e.g., response code 422).

[0167] In one or more aspects, the program does not have to continually check for changes in the currently configured verification certificate list, which speeds up the checking process and eliminates some coding work and testing for each piece of software. The management program does not waste processing time constructing responses that the program would discard anyway. The program has the freedom to obtain verification certificate entries using an entry range that matches its storage management scheme that works best for each piece of software. Using a dynamically updateable certificate store (rather than firmware embedded certificates) allows customers to easily update the certificate store with new verification certificates when new certificates are available for verifying signed code components. A mechanism is provided to associate and display verification certificates in a certificate storage unit with verification certificates obtained by software via, for example, a service element panel, using, for example, a verification certificate name and a verification certificate index. As an example, the program can internally associate verification certificates using, for example, a verification certificate name key ID, a fingerprint, and / or a verification certificate index.

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

[0169] Subcode 3 – Store Verification Certificate Extract

[0170] In one or more aspects, a program (e.g., a boot loader, an operating system, other programs, etc.) can use diagnostic '0320' subcode 3 to obtain the extracted verification key material (in an easily consumable format) currently in the certificate store for the current configuration. This is particularly useful, for example, if the program cannot directly parse the certificate to obtain the verification key material.

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

[0172] In one example, the diagnostic '0320' subcode 3 is valid when the certificate storage facility is installed in a particular architecture and architecture mode (e.g., the z / Architecture instruction set architecture in architecture mode). For other architectures, this check may not be performed, and / or other architectures may perform other checks. Many possibilities exist.

[0173] In one example, the logical address of the verification certificate 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 length of the verification certificate extract block can be, for example, a multiple of 4K bytes. The length of the verification certificate extract block is specified, for example, in multiples of 4K bytes, by the verification certificate extract block input length field, for example, word 0, of the verification certificate extract block.

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

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

[0176] In one example, if a verification certificate extract does not exist for the specified verification certificate extract index range or for the general configuration, the verification certificate extract block output length is set to, for example, a defined value, such as 64. The stored verification certificate extract count is set to, for example, zero, the remaining verification certificate extract count (RVCXC) is set to, for example, zero, and a response code 422, for example, 0001 hexadecimal, is returned to, for example, bit positions 48-63 of general register R1+1.

[0177] In one example, when insufficient storage space is provided in the verification certificate extract block input length field to store at least the first requested verification certificate extract entry, none of the requested verification certificate extract entries are stored, and the verification certificate extract block output length is set to, for example, a defined value, such as 64. The stored verification certificate extract count is set to, for example, zero, the remaining verification certificate extract count is set to, for example, the count of verification certificate extract entries that cannot be stored in the verification certificate extract block, and a response code 422, for example, 0001 hexadecimal, is returned in, for example, bit positions 48-63 of general register R1+1.

[0178] In one example, when insufficient storage space is provided in the verification certificate extract block input length field to store the requested verification certificate extract entries, the maximum number of verification certificate extract entries that fit in the verification certificate extract block is stored in the stored verification certificate extract count of the verification certificate extract block, and the count of the verification certificate extract entries that cannot be stored in the verification certificate extract block is stored in the remaining verification certificate extract count field of the verification certificate extract block.

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

[0180] In one example, the diagnostic '0320' instruction, subcode 1 (Query Verification Certificate Storage Information) previously returned the number of verification certificates, which, in one example, is equal to the number of verification certificates extracted from the machine's public verification certificate store. Thus, the designation of the first and last verification certificate extracts allows the requesting program to obtain the verification extracts it desires, provided the certificate extracts fit within the memory provided to, for example, the firmware. If desired, the program can repeatedly issue the diagnostic '0320' subcode 3 instruction to eventually cause the firmware to return, for example, all verification certificate extracts in the public certificate store for the currently configured machine.

[0181] The provided certificate store token (e.g., as output of subcode 1 and used as input to subcode 3) must match the current certificate token. In one example, if the provided certificate store token does not match the current value, an error is returned. This thus provides a simple technique for ensuring that the authentication certificate (and therefore the authentication certificate extract) in the public certificate store in 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 also issued.

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

[0183] In one example, verification key material is extracted only for specific verification key types. There may not be a verification certificate extract for every verification certificate. For such an implementation, the verification certificate extract entries are not compressed to remove verification certificate extract entries that do not have a valid verification certificate extract. Instead, verification certificate extract entries that do not have a valid verification certificate extract are considered invalid verification certificate extract entries and are indicated in a verification certificate extract entry that only contains a header, and, for example, the verification certificate extract valid (VCXV) flag is set to, for example, zero. For example, when the corresponding verification certificate contains one of the key types for which the verification key material is extracted, the verification certificate extract entry contains the actual verification certificate extract information. This information includes, for example, the time when the verification certificate was first valid, the time when the verification certificate was last valid, information about the verification certificate, information about the verification key type, and an extracted verification key block (XVKB) containing the actual variable-sized verification key.

[0184] In one or more aspects, a program (e.g., a boot loader, an operating system, etc.) issues a diagnostic '0320' instruction specifying subcode 3, a verify certificate extract entry range, and a certificate store token to obtain one or more verify certificate extracts in a certificate store for a current configuration. In one example, if the current certificate store token for the certificate store for the current configuration is different than the specified certificate store token value, the hypervisor returns an error. This mechanism allows the hypervisor to ensure that the list of verify certificate extracts for the configuration does not change when the function is used asynchronously and when they are subsequently retrieved by the 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 a returned / saved certificate store token value (obtained from the diagnostic '0320' subcode 1) to determine if one or more verify certificates have changed.

[0185] In one aspect, the diagnostic '0320' instruction returns one or more verification certificate extracts in the certificate store for the current configuration based on a range of verification certificate extract entries. The one or more verification certificate extracts are returned in a verification certificate extract block that includes, for example, a header followed by one or more verification certificate extract entries. The header includes, for example, a specified first verification certificate extract index and a specified last verification certificate index that are used to determine the range of verification certificate extracts to be stored by the store verification certificate extract function; and a count of verification certificate extract entries (VCXE) stored in the verification certificate extract block. In one example, when insufficient storage space is provided in the verification certificate extract block input length field to store the requested verification certificate extract entries, a count of the verification certificate extract entries that cannot be stored in the verification certificate extract block is stored in the remaining verification certificate extract count field.

[0186] Each verification certificate extract block entry includes, for example, information for one verification certificate extract.

[0187] refer to Figures 8A-8B Further details regarding the verification certificate extract block and the verification certificate extract entries are described. In one example, the verification certificate extract block 800 ( Figure 8A ) includes a public header (e.g., 16 words) followed by zero or more verification certificate extract entries (VCXEs). In one example, selected positions of the public header (e.g., words 0-7) include input data, while other selected positions of the public header (e.g., words 8-15) include output data. In one example, subcode 3 stores a list of verification certificate extracts in an extracted key type format into a verification certificate extract block.

[0188] In one example, the verification certificate extract block 800 includes the following fields:

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

[0190] First Verification Certificate Extract 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 verification certificate extract in the certificate store to be stored in the first verification certificate extract entry. In one example, this value is less than or equal to the value of the last verification certificate extract index; otherwise, a response code 422, e.g., 0304 hexadecimal, is returned in, e.g., bit positions 48-63 of general register R1+1.

[0191] Last Verified Certificate Extract Index 806: This field (eg, bytes 2-3 of word 2) contains an unsigned binary integer (eg, 16 bits) that specifies the index of the verified certificate extract in the certificate store to be stored in the last verified certificate extract entry.

[0192] In one example, a value of zero is a valid index for the first and / or last verified certificate extract index for this instruction. However, because the certificate store maintains a single source of indexes, no certificate extract with an index value of zero is available. A request for a single certificate extract with an index of zero results in the return of zero certificate extracts. A request for multiple certificate extracts starting at zero results in the first returned certificate extract entry containing certificate index one.

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

[0194] Verify Certificate Extract 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 Verify Certificate Extract Block when the operation completes successfully. In one example, this value is greater than or equal to, for example, 64.

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

[0196] Verification Certificate Extracts Stored Count 814: This field (eg, bytes 0-1 of word 10) contains an unsigned integer (eg, 16 bits) that is a count of the verification certificate extracts stored in the verification certificate extracts block.

[0197] Remaining Verification Certificate Extract Count 816: This field (e.g., bytes 2-3 of word 10) contains an unsigned integer (e.g., 16 bits) that is a count of the verification certificate extracts that cannot be stored in the verification certificate extract block due to insufficient storage specified in the verification certificate extract block input length field.

[0198] Verification Certificate Extract Entries 818: In one example, the verification certificate extract block (e.g., words 16 through N) can contain zero or more verification certificate extract entries based on the verification certificate extract block input length and the verification certificate extract range (e.g., from the first verification certificate extract index to the last verification certificate extract index) currently in the certificate store for this configuration. In one example, the verification certificate extract entries have a common header followed by the verification certificate extract in an extracted key type format.

[0199] In one example, each verification certificate extract entry is aligned, for example, word-aligned. Each variable-length field within a verification certificate extract entry is also aligned, for example, word-aligned. In one example, a verification certificate extract entry length (which is, for example, a multiple of four) is used to form gaps between verification certificate extract entries, and a verification certificate extract entry field offset (which is, for example, a multiple of four) is used to form gaps between verification certificate extract entry fields to provide, for example, word boundary alignment. The length of the verification certificate extract entry field includes, for example, a value representing the actual size of the verification certificate extract entry field, and the unused area (gap) after the verification certificate extract entry field contains, for example, zeros.

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

[0201] In one example, if Figure 8B As shown, the verification certificate extract entry 818 includes the following fields:

[0202] Verification Certificate Extract Entry Length 830: This field (eg, word 0) contains an unsigned binary integer (eg, 32 bits) that specifies the number of bytes in the entire Verification Certificate Extract Entry. The Verification Certificate Extract Entry Length field value is, for example, a multiple of 4 bytes.

[0203] Verify Certificate Extract Entry Flags 834: In one example, this field (e.g., byte 0 of word 1) includes a Flags field defined as follows: Bit meaning 0 Verify that the certificate extract is valid (VCXV): When bit 0 is, for example, 1, When the bit is, for example, zero, 1-7 Reserved

[0204] In one example, the verification certificate extract valid flag is used to indicate that the verification certificate extract is invalid for the configuration, rather than removing invalid verification certificate extracts (holes) each time the hypervisor obtains invalid verification certificate extracts (holes) from the machine by compressing the verification certificate extract store and renumbering them using different index values ​​for all currently valid verification certificate extracts.

[0205] In one example, if the verification certificate extract is invalid (VCXV=0), the program may perform the following operations to determine if it is truly invalid:

[0206]

[0207]

[0208]

[0209]

[0210] [Key Type 836: This field (eg, byte 1 of word 1) comprises an unsigned binary integer (eg, 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] In one example, the key type field value is defined as follows: Value meaning 0 Key type not supported 1 ECDSA-NIST Curve P521 2-255 are reserved

[0212] Certificate Index 840: This field (eg, bytes 2-3 of word 1) contains an unsigned binary integer (eg, 16 bits) that specifies the index of the current verification certificate extract in the currently configured certificate store. It also indicates the index of the directly associated verification certificate.

[0213] Verification Certificate Name 842: This field (e.g., words 2-17) contains the name (e.g., 64 bytes) of the verification certificate from which the verification certificate extract was created (as it appears on the service element panel). In one example, the verification certificate name is used to identify the verification certificate extract in the certificate store via, for example, the service element, since the verification certificate extract index is an internal mechanism and is not displayed in 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, for example, the number of bytes in the Key ID field. The Key ID Length field value is, for example, a multiple of 1 byte.

[0215] Verification 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 verification certificate hash (also known as the fingerprint) used to identify the verification certificate from which the extracted material was obtained. In one example, the Verification Certificate Hash Type field value is defined as follows: Value meaning 0 Unsupported authentication certificate hash type 1 SHA2-256 (Secure Hash Algorithm) 2-255 are reserved

[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) that specifies the number of bytes in the Verification Certificate Hash field. The Verification Certificate Hash Length field value is, for example, a multiple of 1 byte.

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

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

[0219] Extracted Authentication 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 Authentication Key Block field. The Extracted Authentication Key Block Offset field value is, for example, a multiple of 4 bytes.

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

[0221] Verify Certificate Validity Expiration Time 858: This field (eg, words 34-35) contains the TOD clock time (eg, the leftmost 8 bytes output of the storage clock extension instruction) from which the verification certificate is invalidated.

[0222] Key ID 860: This field (e.g., word 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, for example, word-aligned.

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

[0224] Extracted Verification Key Block 864: This field of the verification certificate extract entry (e.g., words B+1 to N) includes the extracted verification key block (XVKB). In one example, the extracted verification key block has one or more verification key portions of a specified key type. Each extracted verification key block is aligned, e.g., word aligned. Each variable length field in 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, for example, a multiple of four, and gaps are formed between extracted verification key block fields using an extracted verification key block field offset that is, for example, a multiple of four to provide, for example, word boundary alignment. The extracted verification key block field length includes a value that is the actual size of the extracted verification key block field, and the unused area (gap) after the extracted verification key block field contains, for example, zeros.

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

[0226] In one example, when the specified key type is set to, for example, 0 (unsupported key type), the extracted verification key block includes, for example, unformatted verification key data. The extracted verification key block length field in the verification certificate extract entry includes the number of bytes stored in the extracted verification key block field.

[0227] In one example, when the designated key type is set to, for example, 1 (ECDSA-NIST curve P521), the Elliptic Curve Validation Key Block (ECVKB) shows the format of the validation key.

[0228] refer to Figure 8C An example of an elliptic curve authentication key block is described. In one example, the elliptic curve authentication key block 880 includes the following fields, for example:

[0229] Verification Key Part 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 Part X field. The Verification Key Part X Length field value is, for example, a multiple of 4 bytes.

[0230] Verification Key Part 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 Part Y field. The Verification Key Part Y Length field value is, for example, a multiple of 4 bytes.

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

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

[0233] In one or more aspects, even if the certificate store token value changes while a partial verification certificate extract list is being collected by issuing multiple instances of the diagnostic '0320' instruction, the hypervisor and the program work together to ensure that the program asynchronously obtains the entire verification certificate extract list for the current configuration, for example, in a scatter-gather list for the same certificate store version (same certificate store token value). 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 constructing a response that the program would discard and restart the verification certificate extract collection process.

[0234] The diagnostic '0320' instruction locates each verification certificate of the extracted key type from the certificate store for the current configuration, parses and extracts the verification key material from the verification certificate, and returns them in a verification certificate extract entry in the verification certificate extract format based on the verification certificate extract entry scope. Figure 5A and 5D The return of the verification certificate extract is further described.

[0235] In one example, reference Figure 5A Based on the determination 514 that the diagnostic '0320' subcode 3 function is to be performed, the process 500 performs 516 the function. Figure 5D Further details related to performing the function of storing the verification certificate extract (subcode 3) are described.

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

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

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

[0239] In one example, process 516c returns 590 a response code, such as 0001 hexadecimal (eg, response code 422).

[0240] Returning to query 582, in one example, if there is sufficient storage space to store the requested verification certificate extract, process 516c returns 590 a response code, such as 0001 hexadecimal (eg, response code 422).

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

[0242] Additionally, returning to query 573, if the provided credential store token value does not match the current credential store token value, then process 516c returns a response code, eg, 0306 hexadecimal, indicating an error (eg, response code 422).

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

[0244] In one or more aspects, a machine is configured to locate, parse, extract, and return extracted verification certificate material based on a specified key type, eliminating the need for each program to replicate the same location, complex parsing, and extraction code. In one example, the machine performs granular error detection of one function (subcode 3) using another function (subcode 2) to verify that the extraction was correct. In one example, the machine may need to remove invalid verification certificate extracts (holes), for example, by compressing the verification certificate extract store and renumbering them using different index values ​​for all currently valid verification certificate extracts each time they are obtained from the machine by a hypervisor.

[0245] In one or more aspects, the program does not have to continually check for changes in the list of verification certificate extracts for the current configuration, which speeds up the checking process and eliminates some coding work and testing for each piece of software. The management program does not waste processing time constructing responses that the program would discard anyway. The program has the freedom to use entry ranges to obtain verification certificate extract entries to match its storage management scheme that works best for each piece of software. Using a dynamically updateable certificate store (rather than firmware embedded certificates) allows customers to easily update the certificate store with new verification certificate extracts when new certificates are available to verify signed code components. A mechanism is provided to associate verification certificates in the certificate store with verification certificates obtained by software via, for example, a service element panel, using, for example, a verification certificate name and a verification certificate index, and to display the verification certificates in the certificate store. As an example, the program can internally associate verification certificates using, for example, a verification certificate name, a key ID, a fingerprint, and / or a verification certificate index.

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

[0247] In one or more embodiments, example response codes are defined:

[0248] '0001': The specified subcode was completed successfully.

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

[0250] '0202': Subcode 1 has been specified, but the Verification Certificate Storage Size Block Length field does not contain the minimum value, eg, 128.

[0251] '0204': Subcode 2 has been specified, but the Verification Certificate Block Input Length field value is not a non-zero multiple, such as 4K bytes.

[0252] '0206': Subcode 3 has been specified, but the Verification Certificate Extract Block Input Length field value is not a non-zero multiple, such as 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 verification certificate extract index is greater than the value of the last verification certificate extract index.

[0255] '0306': Subcode 2 or 3 was specified, but the specified certificate store token value does not match the current certificate store token value in the certificate store used for this configuration.

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

[0257] In one example, diagnostic '0320' may encounter the program exceptions listed below. In each case, as an example, instruction execution is suppressed.

[0258]

[0259]

[0260]

[0261]

[0262]

[0263]

[0264]

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

[0266] Example program exceptions include, for example:

[0267]

[0268]

[0269]

[0270]

[0271] In one or more examples, the verification certificate and its corresponding extracted key will have the same index so that the same index is used to match the verification certificate and its corresponding extracted key.

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

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

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

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

[0276] In one or more examples, the hypervisor collects each of these verification certificate extracts (VCXs) from the certificate store for a given configuration and separates them by key type. For each extracted key type, the set of verification certificate extracts is also indexed from 1 to N. However, from the perspective of a given logical partition, a verification certificate extract with a valid index may not contain a valid verification key (i.e., there may be holes where the index contains an invalid verification key or an index without any verification certificate extract information).

[0277] In one or more examples, the boot loader and the operating system are allowed to use different versions of the authentication key.

[0278] In one or more examples, a boot loader and an operating system are configured to obtain a current authentication key from a certificate store for a given configuration when performing a re-initialization.

[0279] Other variations and embodiments are possible.

[0280] Furthermore, although one or more examples of computing environments in which one or more aspects of the present invention may be incorporated and used are described herein, Figures 9A-9B Another embodiment of a computing environment that incorporates and uses one or more aspects of the present invention is shown.

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

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

[0283] In addition, the local central processing unit 37 executes instructions and codes stored in the memory 38. In one specific example, the central processing unit executes emulator code 42 stored in the memory 38, which enables a computing environment configured in one architecture to simulate another architecture (different from the one architecture) and to execute software and instructions developed based on the other architecture.

[0284] refer to Figure 9BFurther details are described regarding the emulator code 42. The guest instructions 43 stored in the memory 38 include software instructions (e.g., related to machine instructions) that are developed to execute in an architecture different from that of the native CPU 37. For example, the guest instructions 43 may be designed to execute on a processor based on another instruction set architecture, but instead, are emulated on the native CPU 37, which may be, for example, an instruction set architecture. In one example, the emulator code 42 includes an instruction fetch routine 44 to obtain one or more guest instructions 43 from the memory 38 and optionally provide local buffering for the obtained instructions. It also includes an instruction conversion routine 45 to determine the type of guest instruction that has been obtained and convert the guest instruction into one or more corresponding native instructions 46. The conversion includes, for example, identifying the function to be performed by the guest instruction and selecting (one or more) native instructions to perform the function.

[0285] In addition, the emulator code 42 includes an emulation control routine 47 to enable execution of native instructions. The emulation control routine 47 can cause the native CPU 37 to execute a routine of native instructions that emulates one or more previously acquired guest instructions, and at the end of such execution, return control to the instruction fetch routine to emulate the next acquired guest instruction or set of guest instructions. The execution of the native instructions 46 can include loading data from the memory 38 into a register; storing data from a register back to the memory; or performing some type of arithmetic or logical operation determined by the conversion routine.

[0286] For example, each routine is implemented in software that is stored in memory and executed by the local central processing unit 37. In other examples, one or more of the routines or operations are implemented in firmware, hardware, software, or some combination thereof. The registers of the emulated processor can be emulated using the registers 41 of the local CPU or by using locations in memory 38. In embodiments, guest instructions 43, native instructions 46, and emulator code 42 can reside in the same memory or can be dispersed across different memory devices.

[0287] According to one or more aspects of the present invention, exemplary instructions that may be simulated are the diagnostic instructions described herein.

[0288] The computing environments described herein are merely examples of computing environments that can be used. One or more aspects of the present invention can 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 aspects of the present invention. For example, each can be configured to implement diagnostics and / or initial program loading processes and / or perform one or more other aspects of the present invention.

[0289] One or more aspects of the present invention relate to computer technology and facilitate processing within a computer, thereby improving its performance. For example, processing associated with validating certificates is facilitated, thereby improving processing within a computing environment. By using a single architectural instruction to perform multiple operations for sub-code, processing associated with certificate storage is pipelined and storage costs are reduced. This improves processing within a processor, computer system, and / or computing environment.

[0290] In one or more aspects, a capability is provided to obtain verification information (e.g., public key and key type) from a trusted source for 1-n keys. The actual keys can be of different types, lengths, etc. In one or more aspects, certificates and certificate extracts are provided. The extracts are provided in a more consumable form because the user does not need to understand how to parse the certificate itself; instead, it is in a standardized (for a specific implementation) form regardless of the certificate type.

[0291] In one or more aspects, current authentication information may be obtained at any time, meaning that a program may be loaded after initial boot, and if loading occurs, the authentication information valid at that time will be used.

[0292] In one or more aspects, the certificate store includes certificates and certificate extracts for specific key types (in one example, not software modules), so there are no predefined software module and corresponding certificate pairs. The program obtains the current set of verification keys from the certificate store by executing instructions and verifies each signed software module using the obtained keys, one at a time.

[0293] In one or more aspects, multiple keys and information associated with each software module allow for authentication of one or more programs to be loaded into memory, etc. In one or more aspects, more than one key and its information may be used to authenticate a single program being loaded into memory and / or to authenticate multiple programs and any combination thereof.

[0294] Other aspects, variations, and / or embodiments are possible.

[0295] In addition to the above, one or more aspects may be provided, supplied, deployed, managed, serviced, etc. by a service provider that provides management of a customer environment. For example, a service provider may create, maintain, support, etc., computer code and / or computer infrastructure that implements one or more aspects for one or more customers. In return, the service provider may receive payment from the customer, for example, under a subscription and / or fee agreement. 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 perform one or more embodiments. As an example, deployment of an application includes providing a computer infrastructure operable to perform one or more embodiments.

[0297] As another aspect, a computing infrastructure can be deployed including integrating computer readable code into a computing system, wherein the code in combination with the computing system is capable of performing one or more embodiments.

[0298] In another aspect, a process for integrating a computing infrastructure may be provided, comprising integrating computer-readable code into a computer system. The computer system includes a computer-readable medium, wherein the computer medium includes one or more embodiments. The code, combined with the computer system, is capable of executing one or more embodiments.

[0299] Although various embodiments are described above, these are merely examples. For example, other instruction formats, operands, and / or registers may be used. Although pages of memory or storage devices are mentioned, one or more aspects may be used for other units or sizes of memory or storage devices. In addition, other data units may be specified (e.g., bytes are only one example). Furthermore, although the hypervisor is described herein as performing certain aspects of one or more embodiments, one or more of these aspects may be performed by one or more additional and / or other entities, components, etc. Furthermore, material for other types of keys may be extracted. Furthermore, other types of certificates may be stored in the certificate store and provided using one or more aspects of the present invention. Many variations are possible.

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

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

[0302] The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed, if any. The description of one or more embodiments has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the forms disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiments were chosen and described in order to best explain the various aspects and practical applications, and to enable others of ordinary skill in the art to understand various embodiments with various modifications as are suited to the particular use contemplated.

Claims

1. A computer program product for facilitating processing within a computing environment, the computer program product comprising: One or more computer-readable storage media and program instructions stored together on the one or more computer-readable storage media, the program instructions being configured to execute a method comprising: obtaining instructions to be executed within the computing environment, the instructions including an opcode indicative of a diagnostic operation; and Executing the instruction, the execution comprising: obtaining a token as input to the instruction; comparing the token to a current token for the configuration of the computing environment; and Based on the token matching the current token, one or more verification credentials are returned from a credential store.

2. The computer program product according to claim 1, wherein The one or more verification credentials returned include one or more verification credentials within a range of verification credentials specified using the control block of the instruction.

3. The computer program product according to claim 1, wherein The returning includes storing the one or more authentication credentials in a control block specified by the instruction.

4. The computer program product of claim 1 , wherein: The instructions are configured to perform a plurality of functions specified by a plurality of subcodes, the instructions being executed based on a selected subcode from the plurality of subcodes, and wherein the method further comprises executing another instance of the instructions based on another selected subcode, the executing the another instance of the instructions comprising: obtaining the token based on executing the other instance of the instruction; comparing the token to the current token for the configuration; and Based on the token matching the current token, one or more verification credential extracts are returned from the credential store.

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

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

7. The computer program product according to claim 6, wherein: The previous execution of the instructions returns storage size information for the configuration, the storage size information to be used to determine an amount of memory to be used to store the one or more authentication credentials.

8. The computer program product of claim 7, wherein: The storage size information includes a plurality of storage sizes corresponding to a verification certificate block, the verification certificate block being used to store at least one verification certificate of the one or more verification certificates.

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

10. The computer program product of claim 6, wherein: The previous execution of the instruction returns storage size information for the configuration, the storage size information to be used to determine an amount of storage to be used to store one or more verification certificate extracts, and wherein the storage size information includes a plurality of storage sizes corresponding to verification certificate extract blocks, the verification certificate extract blocks being used to store at least one of the one or more verification certificate extracts.

11. A computer system for facilitating processing within a computing environment, the computer system comprising: Memory; as well as a processor in communication with the memory, wherein the computer system is configured to perform a method comprising: obtaining instructions to be executed within the computing environment, the instructions including an opcode indicative of a diagnostic operation; and Executing the instruction, the execution comprising: obtaining a token as input to the instruction; comparing the token to a current token for the configuration of the computing environment; and Based on the token matching the current token, one or more verification credentials are returned from a credential store.

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

13. The computer system according to claim 11, wherein: The instructions are configured to perform a plurality of functions specified by a plurality of subcodes, the instructions being executed based on a selected subcode from the plurality of subcodes, and wherein the method further comprises executing another instance of the instructions based on another selected subcode, the executing the another instance of the instructions comprising: obtaining the token based on executing the other instance of the instruction; comparing the token to a current token for the configuration; and Based on the token matching the current token, one or more verification credential extracts are returned from the credential store.

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, and wherein the token was previously returned as an output from a previous execution of the instruction, the previous execution of the instruction being performed based on one of the plurality of subcodes, and wherein the previously returned token is provided as an input to the instruction being executed, the instruction being executed based on another of the plurality of subcodes.

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

16. A computer-implemented method for facilitating processing within a computing environment, the computer-implemented method comprising: obtaining instructions to be executed within the computing environment, the instructions including an opcode indicative of a diagnostic operation; as well as Executing the instruction, the execution comprising: obtaining a token as input to the instruction; comparing the token to a current token for the configuration of the computing environment; and Based on the token matching the current token, one or more verification credentials are returned from a credential store.

17. The computer-implemented method of claim 16, wherein: The returned one or more verification certificates include one or more verification certificates in a verification certificate range specified using a control block of the instruction, and wherein the returning includes storing the one or more verification certificates in the control block specified by the instruction.

18. The computer-implemented method of claim 16, wherein: The instructions are configured to perform a plurality of functions specified by a plurality of subcodes, the instructions being executed based on a selected subcode from the plurality of subcodes, and wherein the method further comprises executing another instance of the instructions based on another selected subcode, the executing the another instance of the instructions comprising: obtaining the token based on executing the other instance of the instruction; comparing the token to a current token for the configuration; and Based on the token matching the current token, one or more verification credential extracts are returned from the credential store.

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

20. The computer-implemented method of claim 19, wherein: The previous execution of the instructions returns storage size information for the configuration, the storage size information to be used to determine an amount of memory to be used to store the one or more verification certificates and an amount of memory to be used to store one or more verification certificate extracts.

Images