MULTIPLE PHYSICAL REQUIREMENT INTERFACES FOR SAFETY PROCESSORS

Abstract

A procedure that includes the following: Communicating a first tenant from a plurality of tenants with a security processor (160) of a computer platform (100) via a first physical request interface (822) of the security processor (160) to acquire ownership of a first instruction execution machine (826) of the security processor (160) connected to the first physical request interface (822); Communicating a second tenant from the plurality of tenants with the security processor (160) via a second physical request interface (824) of the security processor (160) to acquire ownership of a second instruction execution machine (828) of the security processor (160) connected to the second physical request interface (824); Receiving with the security processor (160) a first request (808) from the first tenant in the first physical request interface (822); Receiving with the security processor (160) a second request (816) from the second tenant in the second physical request interface (824); and Processing the first request (808) with the first instruction execution engine (826) and processing the second request (816) with the second instruction execution engine (826) to perform appropriate trusted computational operations.

Description

BACKGROUND

[0001] A computer platform can be vulnerable to a security attack in which a malicious organization attempts to access information stored on the platform or to damage its components. To prevent security attacks, or at least limit the extent of potential damage, the computer platform can have various levels of protection. For example, the platform can have various access control mechanisms, such as firewalls, passwords, keys, and so on. Another example is that the platform can have a secure cryptographic processor, which can provide a range of security features.Security-related features can, for example, serve to ensure that the computer platform consistently behaves as expected and to prove that the computer platform is trustworthy. US 2021 / 0 014 177 A1 describes methods and systems for deterministic packet scheduling and direct memory access (DMA) in network interface controllers (NICs) to reduce latency and jitter for time-critical networks. US 2021 / 0 232 709 A1 describes a system and method for securely reserving hardware security modules, such as cryptographic adapters, for exclusive use by secure guests in a computing environment.It is an object of the invention to propose a method, a security processor, and a computer system that enable multiple tenants to simultaneously and securely access a security processor via multiple physical request interfaces in order to perform trusted computational operations concurrently. This object is achieved by a method according to claim 1, a security processor according to claim 14, and a computer system according to claim 17. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 is a schematic diagram of a computer system with a security processor that includes multiple physical command-response input / output (I / O) interfaces for tenant of the security processor according to an example implementation. Fig. Figure 2 is a schematic representation of the security processor according to an exemplary embodiment. Fig. Figure 3 is a flowchart showing the configuration of the security processor and the processing of instructions by the security processor according to a sample implementation. Fig. Figure 4A is a representation of the shared tenant use of platform configuration registers (PCRs) of the security processor according to an example implementation. Fig. Figure 4B is a representation of the PCR reservation under the tenant of the security processor according to a sample implementation. Fig. Figure 5 is an illustration of consensus-based access control for a protected object stored by the security processor according to a sample implementation. Fig. Figure 6 is a flowchart showing a process of a security processor to perform trusted computational operations according to a sample implementation. Fig. Figure 7 is a schematic diagram of a security processor with multiple physical command-response I / O interfaces according to an implementation example. Fig. Figure 8 is a schematic diagram of a computer platform with a security processor that includes physical interfaces for receiving requests for trusted computing operations according to an example implementation. DETAILED DESCRIPTION

[0002] A secure cryptographic processor, or security processor, for a computer platform can provide trusted computational operations to ensure that the platform consistently behaves as expected. Examples of trusted computational operations include: generating cryptographic keys; storing security artifacts (such as cryptographic keys and certificates); accessing security artifacts; deleting security artifacts; storing integrity measurement dumps; providing signed integrity measurement dumps for remote attestation; encrypting data; decrypting data; and binding cryptographic keys to specific integrity measurement dump states (e.g.,Examples of trusted computational operations include binding a storage device's encryption key to a set of integrity measures; unsealing cryptographic keys; providing nonces for cryptographic communications; signing certificates; providing random or pseudorandom numbers; and so on. Trusted computational operations can also include operations for configuring the security processor and operations for owning the security processor. A Trusted Platform Module (TPM) is an example of a security processor.

[0003] The security processor may have a physical command-response input / output (I / O) interface used to receive requests containing instructions for the security processor and to provide corresponding responses. In this context, a "physical command-response I / O interface" (also referred to here as a "command-response I / O interface") refers to an actual, physical component of the security processor that provides addressable space for one or more tenants of the computer platform to send requests to the security processor and receive corresponding responses from it. As used here, a "tenant" refers to a user component of the security processor that is connected to the command-response I / O interface.A "request" refers to a request for an operation to be performed on or by the security processor. A tenant that makes a request to the security processor can be considered a "requester."

[0004] In accordance with example implementations, a request can contain information such as a command to be executed by the security processor, one or more operands representing parameters associated with the command, and ownership information (as described below) that establishes the requester's right to use the security processor. A specific request might, for example, relate to a trusted computation, the establishment of ownership of the security processor, or the configuration of the security processor. In response to a specific request, the security processor provides an appropriate response, such as an acknowledgment or acceptance of the request, confirmation that the requested action was performed, a rejection of the request, a security artifact (e.g., a cryptographic key, seed, nonce, signed metric, or certificate), and so on.

[0005] The security processor can have an instruction execution engine that executes instructions received via the command-response I / O interface. The execution engine can process one instruction at a time, and accordingly, the security processor's resources can be used to process one instruction at a time.

[0006] Access to the security processor can be restricted to prevent a malicious entity from accessing secure data or otherwise using the security processor for malicious purposes. For example, access to the security processor can be restricted to a single owner at any given time. In this context, the "owner" of the security processor can refer to a tenant who can prove to the security processor that they possess an ownership token (such as a password or authorization session). For instance, when the security processor is powered on, a firmware component of the computer platform, such as a Unified Extensible Firmware Interface (UEFI), can establish an ownership token for the security processor.Requests made by the UEFI to the security processor may, for example, specify the ownership token or a file containing the ownership token to establish the UEFI's right to use the security processor.

[0007] Multiple tenants of the computer platform can utilize the security processor in a time-division multiplexed environment by sharing an ownership token or obtaining their own ownership tokens. For example, the UEFI can establish an ownership token and use it to access the security processor in the computer platform's pre-boot environment (i.e., the environment before control is transferred to the operating system) for boot-related services (such as recording measurements as part of a measured boot process). The operating system can obtain its own ownership token, allowing the operating system and applications to make requests to the security processor in the computer platform's post-boot environment (i.e., the environment after the operating system has loaded and control has been transferred to it).

[0008] When sharing the security processor using time-division multiplexing (TDM), the security processor executes a single instruction for a single tenant at a time. Even when multiple tenants share the security processor using TDM, this level of sharing may not be sufficient to meet the needs of a more modern computer platform architecture that can benefit from the security processor's ability to process instructions for multiple tenants simultaneously. For example, a computer platform might have a Baseboard Management Controller (BMC) and an operating system, both of which could benefit from the security processor's simultaneous use in the platform's post-boot environment.

[0009] In particular, the BMC may be able to provide one or more security-related functions for the computer platform, and these functions may include instructions that are processed by the security processor. For example, the BMC may provide security-related functions such as recording measurements for operating system attestation, verifying the computer platform's hardware, securing the distribution of out-of-band keys or secrets, and so on. One possible approach for the BMC to provide these security-related functions during the post-boot environment could be for the BMC and the operating system to share the security processor. Furthermore, in the computer platform's post-boot environment, the security processor may be used not only by the operating system but also by one or more other tenants, such as...from UEFI (as part of the UEFI platform firmware role). Sharing the security processor by the BMC with one or more other tenants in the post-boot environment can lead to scenarios where multiple tenants need to process instructions for the security processor simultaneously. Because the security processor is not multi-threaded (i.e., the security process cannot process instructions for multiple tenants concurrently), a denial-of-service situation for the security processor can occur.

[0010] According to example implementations, a computer platform includes a multi-threaded security processor capable of processing more than one instruction concurrently. Specifically, according to example implementations, the security processor includes multiple physical command-response I / O interfaces (also referred to here as "command-response I / O interfaces"); and each physical command-response I / O interface can be connected to another instruction execution engine (or "command processor"). In accordance with example implementations, this security processor architecture allows the security processor to process instructions for multiple tenants simultaneously.

[0011] According to example implementations, a first physical command-response I / O interface of the security processor can be accessed and used by a tenant connected to the main and general-purpose processing kernels of the computer platform. Commands sent by the tenant through the first command-response I / O interface can, for example, be executed or processed by a corresponding first command execution machine of the security processor. A second command-response I / O interface of the security processor can be accessed and used by a secondary processor-based tenant, such as a BMC of the computer platform. The BMC can send commands to the security processor through the second command-response I / O interface, and these commands can be executed or processed by a second command execution system of the security processor.

[0012] As a more specific example, according to some implementations, a firmware boot service component, such as a UEFI, can establish ownership of a command execution machine connected to a first command-response I / O interface in a pre-boot environment of the computer platform. Establishing ownership may involve the UEFI setting up an ownership token for the command execution machine. The UEFI can then use this ownership token to submit requests to the security processor via the first physical command-response I / O interface during the pre-boot environment. The first physical command-response I / O interface can also be used by the operating system during the post-boot environment of the computer platform. For example, the operating system can...The security processor can establish its own ownership token so that its commands are executed by a different command execution engine connected to the first physical command-response I / O interface; or the operating system can use the same ownership token as the UEFI. Security processor requests from the operating system and applications can be delivered by a Trusted Service Stack (TSS) to ensure that only one command provided by the operating system or application is delivered to the first command-response I / O interface at a time.

[0013] Another component of the computer platform, such as a BMC, can establish ownership of a command execution machine in the pre-boot environment. This machine is connected to a second physical command-response I / O interface of the security processor. As part of establishing ownership, the BMC can set up an ownership token. Afterward, the BMC can send requests to the security processor via this second physical command-response I / O interface in both the pre-boot and post-boot environments of the computer platform, allowing the security processor to execute commands for the BMC in both environments.

[0014] As another example, according to some implementations, a different tenant, the UEFI runtime services, can share the first command-response I / O interface with the operating system and applications in the computer platform's post-boot environment. To allow the security processor to handle instructions for the operating system and applications concurrently with instructions for the UEFI runtime services, there can be two command execution machines connected to the first command-response I / O interface: a first command execution machine (owned by the operating system) to execute instructions for the operating system and applications, and a second command execution machine (owned by the UEFI) to execute instructions for the UEFI runtime services.

[0015] As another example, according to some implementations, instead of the UEFI runtime services that share the second command-response I / O interface with the operating system and applications, the security processor can include a third command-response I / O interface used exclusively by UEFI runtime services. In these implementations, the security processor can include an instruction execution engine connected to the third command-response I / O interface, which executes the commands received through the third command-response I / O interface.

[0016] This section describes example implementations where the command-response I / O interfaces are associated with a platform hierarchy of the security processor. The security processor may also have hierarchies other than a platform hierarchy, such as a note hierarchy, a memory hierarchy, and a null hierarchy. In accordance with other implementations, the security processor may have multiple physical command-response I / O interfaces (and corresponding multiple instruction execution machines) for a given security processor hierarchy that is not the platform hierarchy. Furthermore, according to example implementations, the security processor may have multiple physical command-response I / O interfaces (and corresponding multiple instruction execution machines) for each hierarchy of multiple security processor hierarchies (e.g.,The security processor may have multiple physical command-response I / O interfaces (and corresponding multiple command execution engines) for a platform hierarchy of the security processor, and multiple physical command-response I / O interfaces (and corresponding multiple command execution engines) for a supporting platform hierarchy of the security processor. Furthermore, according to implementation examples, the security processor may have multiple physical command-response I / O interfaces (and corresponding multiple command execution engines) for one or more hierarchies of the security processor, and a single physical command-response I / O interface (and a corresponding command execution engine) for each of the remaining hierarchy(ies) of the security processor.

[0017] Referring to Fig. 1. As a more specific example, a computer platform 100, in accordance with some implementations, includes a multi-threaded security processor 160, which has several physical command-response I / O interfaces 164 (here also called "command-response I / O interfaces 164") that receive requests for multiple tenants of the security processor 160. Although in Fig. 1 where two specific command-response I / O interfaces 164-1 and 164-2 are shown, the security processor 160 can include more than two command-response I / O interfaces 164 according to example implementations.

[0018] According to example implementations, the security processor 160 can include one or more execution processors or "instruction execution machines 166" for each instruction-response I / O interface 164. Although in Fig. Figure 1 shows two example instruction execution engines 166-1 and 166-2. According to some implementations, the security processor 160 can have more than two instruction execution engines 166. The multiple instruction response I / O interfaces 164 and the multiple instruction execution engines 166 allow the security processor 160 to accommodate situations where multiple tenants can simultaneously make requests to the security processor 160, requiring the security processor 160 to execute multiple instructions concurrently to process these requests.In this context, the “simultaneous” execution or processing of multiple instructions by the security processor 160 refers to the fact that the security processor 160 executes a first instruction of the multiple instructions in a first time interval and executes at least one further instruction of the multiple instructions in a second time interval that overlaps at least partially with the first time interval.

[0019] In general, the instruction execution engine 166 executes a given instruction (directly and / or indirectly through the involvement of other components of the security processor 160, which are discussed here in connection with Fig. (2 described in more detail) executes one or more operations to perform the task(s) specified by the instruction and the operand(s) of the instruction and to produce a result. In accordance with some implementations, the security processor 160 may contain one or more instruction execution engines 166 per instruction-response I / O interface 164.

[0020] The “requests” transmitted to the security processor 160 can, according to example implementations, contain instructions and associated operands to instruct the security processor 160 to perform appropriate trusted computational operations. Furthermore, a specific request for a particular command-response I / O interface 164 can also contain data indicating that the requester possesses an ownership token.

[0021] Examples of trusted computational operations include generating cryptographic keys, distributing cryptographic keys, deleting cryptographic keys, storing security artifacts (e.g., cryptographic keys and certificates); encrypting data; decrypting data; accessing security artifacts; deleting security artifacts; storing integrity measurement digests; providing signed integrity measurement digests for remote attestation; extending platform configuration registers (PCRs); sealing cryptographic keys with PCR states; unsealing cryptographic keys based on appropriate stored PCR states; providing nonces for cryptographic communications; signing certificates; providing random or pseudorandom numbers; and other operations.In accordance with some implementations, the Security Processor 160 can perform one or more trusted computational operations described in the Trusted Platform Module Library Specification, Family 2.0, Level 00, Revision 01.59 (November 2019) published by the Trusted Computing Group (hereinafter referred to as the "TPM 2.0 Specification"). In accordance with some implementations, the Security Processor 160 can also perform one or more trusted computational operations not described in the TPM 2.0 Specification. According to example implementations, the "requests" submitted to the Security Processor 160 can include requests relating to establishing ownership of the respective Instruction Execution Machines 166, including requests to establish ownership tokens.

[0022] A tenant of the Security Processor 160 can generally be a unit consisting of one or more hardware processors (e.g., general-purpose processing cores, embedded processing cores, etc.) that execute machine-executable instructions to utilize the services of the Security Processor 160 (e.g., connecting to the Security Processor 164's command-response I / O interfaces to send commands and receive responses).

[0023] As a more specific example, in accordance with some implementations, the computer platform 100 may contain one or more general-purpose main processing cores 110 (e.g., CPU cores and GPU cores) capable of executing machine-executable instructions to form one or more tenants of the security processor 160. A particular tenant associated with one or more main processing cores 110 may exist in the pre-boot environment of the computer platform 100, in the post-boot environment of the computer platform 100, or in both.

[0024] For example, in the pre-boot environment of the computer platform 100, one or more main processing cores 110 can execute firmware (e.g., BIOS instructions or UEFI instructions) to form firmware boot services 134, which can be a tenant of the security processor 160. In the post-boot environment, one or more processing cores 110 can execute firmware (e.g., UEFI instructions) to form security processor tenants such as a tenant associated with a Trusted Service Stack (TSS) 131 and a tenant associated with firmware runtime services 132. The TSS 131 can submit requests to the security processor 160 on behalf of applications and the operating system 130, and in accordance with some implementations, the TSS 131 can submit the instructions to the security processor 160 one at a time.The TSS 131 can provide an application programming interface (API) that can be called by applications to access functions of the security processor 160. In the case of... Fig. In the implementation shown in Figure 1, TSS 131 is part of the operating system 130. However, according to another implementation, TSS 131 may not be part of the operating system 130.

[0025] Security processor 160 tenants can be connected to processing units other than the main processing cores 110. For example, a management controller of the computer platform 100, such as a BMC 123, can contain one or more embedded processing cores 124 that execute machine-executable instructions 126 to form a security processor 160 tenant in both the pre-boot and post-boot environments of the computer platform 100.

[0026] As another example of a non-main processing core tenant, the computer platform 100 can contain one or more intelligent I / O peripherals 101. The intelligent I / O peripheral 101 can contain one or more processing cores 103 that execute machine-executable instructions 104 (stored in memory 105) to form a tenant of the security processor 160 in the post-boot environment of the computer platform 100. Furthermore, according to some implementations, a dedicated intelligent I / O peripheral 101 can serve as the management controller of the computer platform 100 instead of the BMC 123, and in these implementations, the dedicated intelligent I / O peripheral 101 can be a tenant of the security processor 160 in both the pre-boot and post-boot environments of the computer platform 100.

[0027] The security processor 160 can have any number of command-response I / O interfaces 164, depending on the specific implementation. For the in Fig. In the example implementation shown and described in more detail below, the security processor 160 can have a command-response I / O interface 164-1 connected to the main processing cores 110, and a command-response I / O interface 164-2 connected to the BMC 123. Command-response I / O interface 164-1 can, for example, be a physical bus interface for a bus 150 of the computer platform 100, and command-response I / O interface 164-2 can, for example, be a physical bus interface for another bus 154 of the computer platform 100. Buses 150 and 154 can be any number of different buses, such as an inter-integrated (I) bus. 2 C), an improved I 2 C-Bus (or “I 3C-Bus”), a Serial Peripheral Interface (SPI) bus, an extended SPI (eSPI) bus, or another bus.

[0028] According to example implementations, the physical command-response I / O interface 164-1 can be used by tenants formed by the main processing cores 110, such as the firmware boot services 134 (one tenant), the firmware runtime services 132 (another tenant), and the TSS 131 (another tenant). Depending on the specific implementation, the security processor 160 may have one or more command execution engines 166 to process or execute the instructions received through the command-response I / O interface 164-1. For example, according to some implementations, the security processor 160 may have a single command execution engine 166 to execute the instructions received through the command-response I / O interface 164-1 from the firmware boot services 134, the firmware runtime services 132, and the TSS 131.In these example implementations, the tenants of the command-response I / O interface 164-1 can share an ownership token for the command execution machine 166.

[0029] In accordance with other example implementations, the security processor 160 can have two command execution engines 166 for the command-response I / O interface 164-1. A first command execution engine 166 executes the commands received from the firmware boot services 134 in the pre-boot environment and executes the commands received from the TSS 131 in the post-boot environment. A second command execution engine 166 executes the commands received from the firmware runtime services 132 in the post-boot environment. In accordance with other implementations, the security processor 160 can have one command execution engine 166 for each tenant of the physical command-response I / O interface 164-1.

[0030] The security processor 160 can, in accordance with example implementations, have a special command execution engine 166 to execute commands received by the BMC 123 via the command-response I / O interface 164-2.

[0031] In accordance with some implementations, the security processor 160 can have multiple command-response I / O interfaces 164 connected to the same bus of the computer platform 100. For example, according to some implementations, the security processor 160 can have a first command-response I / O interface 164 connected to the bus 150 to receive commands from the firmware runtime services 132 and the firmware boot services 134. The security processor 160 can further include a second command-response I / O interface 164 connected to the bus 150 to receive commands from the TSS 131. The security processor 160 can also include one or more additional command-response I / O interfaces 164 connected to the bus 150 to receive commands from one or more intelligent I / O peripherals 101.

[0032] According to some implementations, a given physical bus interface can be connected to multiple command-response I / O interfaces. For example, in some implementations, different logical overlays can be associated with a given physical bus interface to create multiple physical command-response I / O interfaces (i.e., each command-response I / O interface is formed from the bus interface and a different logical overlay).

[0033] In accordance with other example implementations, the security processor 160 can have a command-response I / O interface 164 for each tenant of the security processor 160.

[0034] The computer platform 100, as defined in examples, can be a modular unit comprising a frame or chassis. Furthermore, this modular unit can include hardware attached to the chassis and capable of executing machine-executable instructions. A blade server is one example of a computer platform 100 according to a sample implementation. However, according to other implementations, the computer platform 100 can also be any number of other platforms besides a blade server, such as a rack-mounted server, a client, a desktop computer, a smartphone, a laptop, a tablet computer, a modular switch, a storage array, a cluster node, and so on.

[0035] An "intelligent I / O peripheral" (e.g., an intelligent network interface controller or "intelligent NIC") refers to a peripheral device that offloads processing operations traditionally performed by the main processing cores of older computer systems. For example, a specific intelligent I / O peripheral 101 of computer platform 100 can provide backend I / O services for platform 100. These I / O services might include, for example, network virtualization services (e.g., overlay network services, virtual switchboard services, virtual routing services, and network function virtualization services), network storage services, network monitoring services, storage acceleration services (e.g., NVMe-based services), security services (e.g., cryptographic services and network firewall services), and so on.

[0036] As part of delivering backend I / O services, the intelligent I / O peripherals 101 can submit requests to the security processor 160. According to example implementations, the intelligent I / O peripherals 101 can provide backend I / O services as part of a cloud-centric (or "cloud-native") architecture. In this way, according to example implementations, the computer platform 100 can be one of several compute resources 191 that are part of a cloud computing system 99. In these example implementations, one or more of the intelligent I / O peripherals 101 of the computer platform 100 can be intelligent network interface controllers (NICs).

[0037] As in Fig. As shown in Figure 1, the intelligent I / O peripherals 101 can be connected to the computing resources 191 and the cloud tenant computer systems or clients 193 via the network structure 190. In general, the network structure 190 can be connected to one or more types of communication networks, such as (for example) Fibre Channel networks, Gen Z fabrics, dedicated management networks, local area networks (LANs), wide area networks (WANs), global networks (e.g., the Internet), wireless networks, or any combination thereof.

[0038] The main processing cores 110 can run different instances of applications associated with different cloud tenants (e.g., application instances running in virtual machines, in specific containers, etc.) that are connected to cloud tenant-associated clients 193 of the cloud computing system 99. The execution of the cloud tenant applications can utilize backend I / O services provided by the intelligent I / O peripherals 101. According to example implementations, the processing core(s) 103 of the intelligent I / O peripheral 101 can execute instructions 104 to provide one or more backend I / O services. As part of an intelligent I / O peripheral device 101 that provides backend I / O services, the intelligent I / O peripheral device 101 can be a tenant of the security processor 160 and, as such, make requests to the security processor 160.

[0039] According to example implementations, the BMC 123 can be an embedded system mounted on a motherboard of the Computer Platform 100. According to other implementations, the BMC 123 can be an expansion card connected to a slot on the Computer Platform 100 motherboard. Depending on the specific implementation, the BMC 123 may contain one or more semiconductor packages (or "chips") and one or more semiconductor chips. According to further implementations, the BMC 123 may not contain any semiconductor packages mounted on the motherboard, or it may not be an expansion card.

[0040] The BMC 123, as part of its management layer, can perform various administrative tasks for the Computer Platform 100, including monitoring sensors (e.g., temperature sensors, fan speed sensors), monitoring the operating system status, monitoring the power status, logging computer system events, and providing administrative functions that can be remotely controlled by a Remote Management Server 194. Furthermore, the BMC 123 can enable operations to be performed when the Computer Platform 100 is powered off and before the operating system has booted; and the BMC 123 can be used to perform recovery operations after an operating system or computer system failure. According to example implementations, the BMC 123 can include a network interface to communicate with the Remote Management Server 194 over the Network Infrastructure 190.In accordance with other implementations, the BMC 123 can communicate with the Remote Management Server 194 via passthrough communication through an intelligent I / O peripheral device 101.

[0041] As part of its security layer, the BMC 123 can perform various security-related tasks for the Computer Platform 100, such as validating BMC firmware before it is executed. Security-related tasks can also include validating UEFI and BIOS firmware after powering on or resetting the Computer Platform 100, before the firmware is executed by the Main Processing Core(s) 110. Monitoring software measurements (operating system kernel measurements) to detect security issues can also be performed. Updating the firmware can be another security-related task. Furthermore, as part of its security-related tasks, the BMC 123 can measure a UEFI boot block and extend a PCR state stored in the Security Processor 160 to include the measured UEFI boot state.The BMC 123 can perform a number of other security-related tasks, such as securing the distribution of out-of-band keys / secrets, verifying the hardware of the computer platform 100 via the platform certificate, and so on. For these security-related roles, the BMC 123 can be a tenant of the security processor 160 and, as such, can submit requests to the security processor 160 via the command-response I / O interface 164-2, corresponding to the security-related roles. Furthermore, the BMC 123 can submit these requests to the security processor 160 in both the pre-boot and post-boot environments of the computer platform 100.

[0042] As a specific example of requests transmitted from the BMC to the security processor 160, the BMC 123, according to some implementations, can perform an initial integrity measurement for the computer platform 100 in the pre-boot environment, such as measuring a UEFI boot block. The BMC 123 can, for example, send a request to the security processor 160 via the command-response I / O interface 164-2 to calculate a hash of the UEFI boot block. Furthermore, the BMC 123 can, for example, send a request to the security processor 160 via the command-response I / O interface 164-2 to extend the PCR number zero (or "PCR0") of the security processor 160 based on the calculated hash.The BMC 123 can transmit requests to the security processor 160 in the post-boot environment of the computer platform 100 via the command-response I / O interface 164-2 for purposes such as performing integrity measurements of the operating system 130 and the corresponding extension of a PCR state, performing integrity measurements of applications and the corresponding extension of a PCR state, verifying the hardware of the computer platform 100 using a platform certificate, securing the distribution of out-of-band keys / secrets, and so on.

[0043] A "BMC," or "Baseboard Management Controller," is a specialized service processor that monitors the physical state of a server or other hardware using sensors and communicates with a management system over a management network. The Baseboard Management Controller can also communicate with applications running at the operating system level through an IOCTL (Input / Output Controller) interface driver, a REST (Representational State Transfer) API, or another system software proxy that facilitates communication between the Baseboard Management Controller and the applications. The Baseboard Management Controller can access hardware devices located within a server chassis, including system memory, at the hardware level. The Baseboard Management Controller may also be able to directly modify these hardware devices.The baseboard management controller can operate independently of the operating system of the system in which it is located. The baseboard management controller can reside on the motherboard of the server or other device being monitored. The fact that a baseboard management controller is mounted on the motherboard of the server / hardware being monitored, or otherwise connected or attached to it, does not prevent the baseboard management controller from being considered "separate" from the server / hardware being monitored. As used here, a baseboard management controller has management functions for subsystems of a computer device and is separate from a processing resource that runs a computer device's operating system. The baseboard management controller is separate from a processor, for example.a central processing unit that runs a high-level operating system or hypervisor on a system.

[0044] For the purpose of providing requests to the security processor 160, the BMC 123 contains one or more embedded processing cores 124. According to example implementations, the embedded processing cores 124 can execute machine-executable instructions 126, which are stored in a memory 128 of the BMC 123, to perform the management and security-related tasks of the BMC, which include the transmission of requests by the BMC 123 to the security processor 160.

[0045] In accordance with example implementations, the command-response I / O interface 164 is an actual interface that contains actual hardware and can contain machine-executable instructions. According to example implementations, the command-response I / O interface 164 can contain one or more processing kernels that execute machine-executable instructions to perform one or more of the functions described herein, such as receiving requests, transmitting commands to a command-executing engine of the security processor 160, handling entity authentication, granting ownership, accepting owner requests, rejecting non-owner requests, transmitting responses to requests, and so on. In accordance with other implementations, one or more functions of the command-response I / O interface 164 can be performed by hardware logic.by a non-processing core circuit, such as a complex programmable logic device (CPLD), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and so on.

[0046] A specific command-response I / O interface 164 can be "owned" at a given time. In this context, the fact that a command-response I / O interface 164 "owns" a particular tenant means that the interface 164 is associated with that tenant. According to example implementations, a specific command execution machine 166 is "owned" based on a corresponding ownership token. According to these example implementations, the command execution machine 166 executes commands associated with its ownership token (i.e., it executes commands for a tenant that provides the ownership token) and does not execute commands that are not associated with its ownership token.

[0047] For example, a tenant of security processor 160 can establish ownership of an instruction execution machine 166, which is connected to a specific command-response I / O interface 164, as follows. First, the tenant can request a notation from security processor 160 that identifies it as the owner. The notation could be, for example, a certificate signed by a certificate authority (CA). Furthermore, the certificate could contain a public key from a public-private key pair, so that security processor 160 possesses the private key (e.g., a notation key). The tenant can generate an ownership token, and after the tenant has authenticated the notation provided by security processor 160, the tenant can sign the ownership token with the public key to encrypt the ownership token.The entity can then send the encrypted ownership token to the command execution machine 166. Other techniques can be used to establish ownership of a command execution machine 166 and set up an ownership token, in accordance with other implementations.

[0048] According to example implementations, the security processor 160 can be a "root of trust" for storage and a "root of trust" for reporting for the computer platform 100. In this context, a "root-of-trust device" or "RoT device" can be a device that behaves in an expected manner, as any misbehavior of the RoT device might not be detected. In other words, the RoT device can be inherently trusted software, hardware, or a combination of both. An RoT device can contain compute units. The compute engine can be software that works with hardware in the RoT device, hardware of the RoT device itself, or a combination of both. For example, an RoT device can contain a Root of Trust for Storage (RTS). The RTS can be a compute module capable of generating an accurate summary of values.

[0049] According to example implementations, the Security Processor 160, as part of its storage trust root, has a memory, such as a PCR memory, that stores data representing hash values ​​of integrity measurements (e.g., integrity measurement digests) from the computer platform's trusted data processing base. In accordance with example implementations, the PCR memory can be extended to include a new integrity measurement by using a "PCR extension instruction." Executing the PCR extension instruction causes a hash to be calculated based on the current contents of the PCR and the new integrity measurement(s), and this calculated hash is then stored in the PCR memory in place of the current contents.In other words, in accordance with the example implementations, the PCR extension instruction updates an integrity measurement digest stored in the PCR memory of the Security Processor 160.

[0050] The Security Processor 160, in accordance with example implementations, can take the form of a semiconductor package (or "chip") mounted on a mainboard of the Computer Platform 100. In addition to PCR memory, the Security Processor 160 can include memory for the secure storage of security artifacts, such as cryptographic keys, passwords, sealed cryptographic keys, certificates, public keys, private keys, etc. The Security Processor 160 includes other cryptographic processing components, which are described in Fig. Figure 2 is shown and described below. The Security Processor 160 can be designed according to industry standards to provide hardware-based security features while resisting tampering and malicious software. In accordance with some implementations, the Security Processor 160 can be a TPM.

[0051] Among other features, the computer platform 100, in accordance with example implementations, can include system memory 114, bus infrastructure, storage devices, I / O devices, etc. According to example implementations, the system memory 114 and other memories and storage media discussed here are non-transient storage media that can be formed from semiconductor memory devices, memristor-based memory devices, magnetic memory devices, phase-change memory devices, a combination of devices from one or more of these memory technologies, etc. The system memory 114 can consist of both volatile and non-volatile memory devices.

[0052] In accordance with example implementations, the bus infrastructure of the computer platform 100 can include one or more bridges 118 that can be connected to the system memory 114, the intelligent I / O peripherals 101, the BMC 123, and the security processor 160 to establish communication between these components. In accordance with some implementations, the main processing core 110 can contain one or more semiconductor packages (or "chips"), and the main processing core 110 can include a north bridge 118 that includes a memory controller (for accessing the system memory 114) and PCIe root ports. The computer platform 100 can also include a south bridge 118 that provides I / O ports such as Serial Advanced Technology Attachment (SATA) ports, Universal Serial Bus (USB) ports, Low Pin Count (LPC) ports, SPI ports, eSPI ports, and so on.According to some implementations, the North Bridge 118 can be part of the main processing core 110. According to other implementations, the North and South Bridges can be combined into a single Bridge 118; and according to some implementations, this single Bridge 118 can be part of the main processing core 110.

[0053] In Fig. Figure 2 shows the architecture of the Security Processor 160 according to an example implementation. Fig. 2 in conjunction with Fig. 1. In some implementations, the command-response I / O interfaces 164-1 and 164-2 decode signals from the associated buses 150 and 154, respectively, and encode signals on these buses to receive requests and provide corresponding responses. Each command-response I / O interface 164 can contain one or more buffers (e.g., first-in-first-out (FIFO) buffers) for temporarily storing data transmitted to and from the associated bus. For a given command-response I / O interface 164, the data coming in from the bus can represent tenant requests and, as such, commands to be processed by one or more instruction execution modules of the safety processor 160. Furthermore, for a given command-response I / O interface 164, the outgoing data can represent responses to the tenant requests.The command-response I / O interfaces 164 can communicate with other components of the safety processor 160 via a bus infrastructure 201, which may include one or more buses, one or more bridges, etc.

[0054] At the in Fig. In the example implementation shown in Figure 2, the 160 security processor comprises two instruction execution engines, 166-1 and 166-2. For example, instruction execution engine 166-1 can process or execute instructions received from the instruction response I / O interface 164-1, and instruction execution engine 166-2 can process or execute instructions received from the instruction response I / O interface 164-2. Although in Fig. Figure 2 shows that one instruction execution engine 166 is assigned to each instruction response I / O interface 164. In accordance with other implementations, a given instruction response I / O interface 164 may have multiple dedicated instruction execution engines 166 assigned to execute the instructions received from the interface 164. Depending on the specific implementation, the instruction execution engine 166 may consist of one or more processing cores that execute instructions, hardware logic, or a combination of processing cores and hardware logic.

[0055] In accordance with some implementations, the security processor 160 may have a group or pool of available instruction execution machines 166; and the security processor 160 may be configured with assignments between the instruction execution machines 166 and the instruction response I / O interfaces 164. Specifically, in accordance with example implementations, the instruction response I / O interface 164-1 may be considered the primary interface of the security processor 160, and the first owner (i.e., the first tenant to establish an ownership token via interface 164-1, such as the UEFI) may configure one or more features of the security processor 160; that is, the first owner may establish or set one or more configuration policies for the security processor 160.

[0056] For example, according to some implementations, the initial owner can specify the activation or deactivation of each of the other command-response I / O interfaces 164 (i.e., activate or deactivate interfaces 164 except for interface 164-1). As a more specific example, according to some implementations, the UEFI can set the initial ownership token via command-response I / O interface 164-1, and after setting the initial ownership token, the UEFI can activate or deactivate command-response I / O interface 164-2. According to other example implementations, the security processor 160 can contain more than two command-response I / O interfaces 164, and the initial owner can selectively deactivate and activate other command-response I / O interfaces 164.According to example implementations, the initial owner of a given command-response I / O interface 164 can assign a number of command execution machines 166. Regardless of the configuration policy(ies) set by the initial owner, according to some implementations, the initial owner can lock the configuration so that it cannot be changed afterwards (e.g., not until the next power-on).

[0057] In accordance with some implementations, setting and locking configuration policies may involve the initial owner accessing a configuration space of the security processor 160, such as a volatile memory area 240 or another memory area of ​​the security processor 160. In accordance with example implementations, a management engine 230 (or "management processor") of the security processor 160 may respond to the configuration data stored in the configuration space by the original owner to perform actions indicated by the configuration data. These actions may include enabling certain command-response I / O interfaces 164, disabling certain command-response I / O interfaces 164, assigning command-execution engine(s) 166 to command-response I / O interfaces 164, and so on.After the initial owner has written configuration data to the configuration space, the management machine 230 can, according to example implementations, set a lock bit to prevent further changes to the configuration policies until the next time the security processor 160 is turned on.

[0058] The management engine 230 can perform a variety of other functions for the security processor 160, such as controlling whether a command-response I / O interface 164 accepts or rejects a given request; verifying an ownership token provided by a requester to determine whether the provided ownership token matches an ownership token established for the corresponding command execution engine 166; coordinating components (described below) of the security processor 160 to provide functions for processing a given command executed by a command execution engine 166; and controlling access to a protected object (as described below in conjunction with Fig. 5); Control of the sharing of PCR benches (as below in conjunction with Fig. 4A described); control of PCR bank reservations (as below in conjunction with Fig. 4B described); and so on.

[0059] In accordance with example implementations, the management machine 230 can enforce the respective ownership rights of the instruction execution machines 166. In this context, "enforcing" ownership for an instruction execution machine 166 means that the management machine 230 allows an instruction execution machine 166 to process instructions that correspond to the owner token for the instruction execution machine 166 and prevents the instruction execution machine 166 from executing instructions that are not associated with the owner token.

[0060] According to some implementations, the management engine 230 can contain one or more processing cores 234 that execute machine-executable instructions 238 stored in memory 239 to perform one or more of these functions. According to other implementations, the management engine 230 can consist wholly or partially of hardware logic, i.e., circuits of non-processing cores, such as a CPLD, an ASIC, an FPGA, etc.

[0061] As in Fig. As shown in Figure 2, the security processor 160, in accordance with some implementations, can include components for performing various trusted computational operations. These components can include, for example, a hash engine 214 for determining hashes, one or more symmetric engines 216 for performing symmetric encryption and decryption, a key generation engine 204 for generating cryptographic keys, and a random number generator engine 208 for generating random or pseudorandom numbers. The security processor 160 can also include a power sensing engine 212 for sensing power state transitions of the computer platform 100. As shown in Fig. As shown in Figure 2, the security processor 160, according to some implementations, can include non-volatile memory 250 that stores security artifacts for the security processor 160, such as a platform seed, an endorsement seed, a storage seed, cryptographic keys, etc. Furthermore, the security processor 160 can include volatile memory 240 in which, for example, integrity measurement data corresponding to PCR banks 242, data representing used keys, etc., can be stored. Each of these components of the security processor 160 can, according to example implementations, be formed from a processor core that executes machine-executable instructions, or it can be formed wholly or partially by hardware logic, i.e., by circuits without a processing core, such as a CPLD, an ASIC, an FPGA, etc.

[0062] As from Fig. 3 in conjunction with Fig. As can be seen from Figure 1, the computer platform 100, in accordance with some implementations, can execute a process 300 for configuring and using the security processor 160. In Fig. Figure 3 shows two example request paths corresponding to the tenant of command-response I / O interface 164-1 (one path) and BMC 123 (the other path). Specifically, one request path is connected to command-response I / O interface 164-1 and includes blocks 302, 304, 308, 312, and 320. The other request path is connected to command-response I / O interface 164-2 and includes blocks 315, 316, and 324.

[0063] Process 300 begins in a pre-boot environment 360 of computer platform 100, which responds to a power-on or reset of computer platform 100. As in Fig. As shown in Figure 3, a firmware boot service 134 (e.g., a UEFI firmware service) takes ownership (block 304) of a command execution machine 166 connected to the command response I / O interface 164-1, and as part of taking ownership, the firmware boot service 134 creates an ownership token. In accordance with example implementations, the firmware boot services 134 can share the ownership token with one or more other tenants of the computer platform 100, such as the TSS 131 (e.g., the firmware boot services 134 can share the ownership token as a UEFI variable).

[0064] Since the firmware boot service 134 is the initial owner, it can, according to example implementations, set one or more configuration policies of the security processor 160, as shown in block 308. In this way, according to some implementations, the firmware boot service 134 can enable or disable the command response I / O interface 164-2, and possibly one or more other command response I / O interfaces 164 of the security processor 160. After setting the configuration policy(ies) of the security processor 160, the firmware boot service 134 can then set a lock on the policy(ies).

[0065] In Block 312, the Firmware Boot Services 134 transmit commands and receive responses from the Security Processor 160 via the Command-Response I / O Interface 164-1 in the Pre-Boot Environment 360 of the Computer Platform 100. Furthermore, in the Pre-Boot Environment 360, the BMC 123 can, according to Block 315, take ownership of a Command Execution Machine 166 connected to the Command-Response I / O Interface 164-2, including the establishment of an ownership token. The BMC 123 can then transmit commands to the Security Processor 160 via the Command-Response I / O Interface 164-2 and receive responses from it, as shown in Block 316.

[0066] In a post-boot environment 361 of the computer platform, the TSS 131 and the firmware runtime services 132 can share the ownership token for the command-response I / O interface 164-1, as shown in block 320, in accordance with example implementations. It should be noted that, according to other example implementations, the TSS 131 can use a different command-response I / O interface 164 than the one used by the firmware runtime services 132. As shown in block 324, the BMC 123 can also send commands to and receive responses from the security processor 160 via the command-response I / O interface 164-2 in the post-boot environment 361 of the computer platform.

[0067] In accordance with some implementations, a specific resource of the Security Processor 160, such as one or more PCRs, can be shared by the tenants, and this sharing can be controlled at the command level in accordance with example implementations. Fig. Figure 4A, for example, is a representation of the shared use of PCRs by the BMC and the firmware boot services according to example implementations. With reference to Fig. 4A in conjunction with Fig. 1 and Fig. 2. According to some implementations, the firmware boot services 134 and the BMC 123 can have shared access to a PCR bank 242-1 to a certain extent. In Fig. Figure 4A shows PCR extension requests 401, which are sent by the firmware boot services 134 to the command-response I / O interface 164-1 and result in corresponding responses 402. Fig. 4A also shows PCR extension requests 403, which are transmitted by the BMC 123 to the command-response I / O interface 164-2 and result in corresponding responses 405.

[0068] More specifically, the BMC 123 can send a PCR extension command via the 164-2 command-response I / O interface to record a measurement of the UEFI boot block in PCR register number zero (hereafter referred to as "PCR0 408"). This allows the BMC 123 to independently check both the UEFI and BMC firmware and software stacks. In this way, the BMC 123 can extend PCR0 408 to include an initial UEFI boot block measurement.

[0069] As in Fig. As shown in Figure 4A, the firmware boot services 134 may be permitted to extend PCRs 409 of PCR bank 242-1, with the exception of PCR0 408. Furthermore, in accordance with some implementations, both the firmware boot services 134 and the BMC 123 may have read access to all PCRs of PCR bank 242-1; and the BMC 123 may not be permitted to extend the other PCRs 409. As shown in Fig. Represented as 4A with the reference number 420, the management machine 230, in accordance with some implementations, can regulate access permissions to the PCR bank 242 to control sharing and access restrictions by monitoring, at the command level, the commands and operands received via the command-response I / O interfaces 164-1 and 164-2.

[0070] Although the PCRs described above are for illustrative purposes only, the shared resource may be something other than an integrity measurement register, in accordance with other implementations. For example, according to some implementations, the shared resource may be a specific area or areas of volatile memory 240 ( Fig. 2).

[0071] Fig. Figure 4B shows a PCR bank reservation 470, which is managed by the security processor 160 in accordance with example implementations. More precisely, with reference to Fig. 4B in conjunction with Fig. 1 and Fig. 2. In accordance with some implementations, the security processor 160 reserves one PCR bank 241-1 for the firmware boot service 134 and another PCR bank 242-2 for the BMC 123. The management engine 230 performs command-level access control 420 on the corresponding command-response I / O interfaces 164-1 and 164-2. The firmware boot service 134, represented by reference number 474, can record its boot measurements in the associated PCR bank 242-1 (via PCR extension requests), and the BMC 123 can record its boot measurements in the associated PCR bank 242-2 (via PCR extension requests). This allows independent testing of both the firmware boot service 134 and the firmware and software stack of the BMC 123.It should be noted that with this PCR bank reservation, in accordance with some implementations, the BMC 123 is still allowed to access PCR bank 242-1 to record an initial boot block measurement (e.g., to record an initial UEFI boot block measurement using a PCR extension command directed to PCR0).

[0072] Fig. Figure 5 shows an illustration 500 of the security processor 160, which governs access to a protected object 504 (e.g., a cryptographic key, seed, certificate, or secret) stored in the security processor 160, according to example implementations. With reference to Fig. 5 in conjunction with Fig. 1 and Fig. In this example, a specific requester sends a request 509 through its associated command-response I / O interface 164 to access (e.g., read, modify, or delete) the protected object 504. In accordance with example implementations, the management engine 230 can use a consensus-based approval model to govern access to the protected object 504. As a result of applying the consensus-based approval model, the management engine 230, in accordance with example implementations (as illustrated by reference number 510), either sends an authorization to interface 164 allowing the request 509 to proceed or sends a rejection of the request 509 to interface 164.

[0073] In accordance with example implementations, the consensus-based approval model can correspond to an authorization policy 516 for the protected object 504. According to some implementations, for example, the authorization policy 516 can be set or configured by the tenant that creates the protected object 504. According to another implementation, the authorization policy 516 can be created by the original owner of the security processor 160. Generally, in accordance with example implementations, the authorization policy 516 defines a "consensus" and / or controls how the consensus governs access to the protected object 504.

[0074] In accordance with example implementations, each Command Execution Machine 166 can contain an Authorization / Deny Token 511 (referred to here as "Token 511"), which can be set or configured by the respective owners of the Command Execution Machine 166. Token 511 represents a "vote" (i.e., approval or denial) to control whether the Request 509 is approved or denied. Furthermore, in accordance with example implementations, the vote represented by Token 511 can depend on the type of access requested by the Request 509. For example, a particular Token 511 can represent a request for read access to the protected object 504, and Token 511 can represent a denial for a request to modify the protected object 504.In accordance with some implementations, the 511 token can also represent different sets of access-related votes for different types of protected 504 objects and / or different security classifications for the 504 objects. In accordance with some implementations, a given command execution machine 166 can store multiple 511 tokens, each 511 token representing access-related votes for a specific category (e.g., the command execution machine 166 can contain one 511 token representing access-related votes for keys and another 511 token representing access-related votes for certificates).

[0075] In accordance with example implementations, the management machine 230 can grant or deny the 509 request based on a match between token 511 and authorization policy 516 for the protected object 504. In some implementations, the management machine 230 grants or denies the 509 request based on a match between token 511, controlled by authorization policy 516. Authorization policy 516 can consist of any number of different policies to determine whether consensus has been reached. For example, reaching consensus might mean that a simple majority of the command execution machines 166 (via their respective tokens 511) approve or deny the 509 request.Reaching consensus can refer, for example, to allowing access to the protected object 504 if a predetermined number of command execution machines 166 (via their respective tokens 511) permit the request 509; otherwise, the request 509 is denied. Another example is that reaching consensus can refer to allowing the request 509 if the token-based authorizations are unanimous; otherwise, the request 509 is denied. In accordance with some implementations, the authorization policy 516 can specify different definitions of consensus depending on the type of access requested.

[0076] Referring to Fig. Section 6 includes a process 600, as described in example implementations, in which a first tenant from a plurality of tenants communicates with a security processor of a computer platform via a first physical request interface of the security processor (block 604) to acquire ownership of a first instruction execution machine of the security processor connected to the first physical request interface. Process 600 also includes a second tenant from the plurality of tenants communicating with the security processor via a second physical request interface of the security processor (block 608) to acquire ownership of a second instruction execution machine of the security processor connected to the second physical request interface.Process 600 involves the security processor receiving an initial request from the first tenant via the first physical interface (Block 612) and the second processor receiving a second request from the second tenant via the second physical request interface (Block 616). According to Block 620, Process 600 includes the processing of the first request by the first instruction execution machine and the processing of the second request by the second instruction execution machine to perform the appropriate trusted computational operations.

[0077] According to Fig. Section 7 includes a security processor 700, in accordance with example implementations, with a variety of physical command-response I / O interfaces, including a first physical command-response I / O interface 704 and a second physical command-response I / O interface 708. The security processor 700 includes a first execution processor 718 for processing instructions 706 provided by a first owner to the first execution processor 718 and received at the first physical command-response I / O interface 704 to perform cryptographic processing operations. The security processor 700 includes a second execution processor 722 for processing instructions 710 provided by a second owner to the second execution processor 722 and received at the second physical command-response I / O interface 708 to perform cryptographic processing operations.The security processor 700 includes a management processor 714 for enforcing a first ownership corresponding to the first owner and for enforcing a second ownership corresponding to the second owner.

[0078] According to Fig.Specification 8 includes a computer platform 800, in accordance with example implementations, comprising at least one processing core 804, a baseboard management controller 812, and a security processor 820. The processing core(s) 804 provide first requests 808 for first trusted computational operations. The baseboard management controller 812 provides second requests 816 for second trusted computational operations. The security processor 820 contains a variety of execution machines, including a first execution machine 826, which is associated with the first physical interface 822 to perform the first trusted computational operations in response to the first requests 808, and a second execution machine 828, which is associated with the second physical interface 824 to perform the second trusted computational operations in response to the second requests 816.The 820 security processor includes a variety of physical interfaces, including a first physical interface 822 for receiving the first requirements 808 and a second physical interface 824 for receiving the second requirements 816.

[0079] In accordance with example implementations, receiving the first request at the first physical request interface involves receiving the first request from a main processor of the computer system. Furthermore, receiving the second request at the second physical request interface involves receiving the second request from a different unit of the computer system than the main processing core. A particular advantage is that a security processor can be used in relatively complex computer architectures where multiple requesters can utilize the security processor concurrently.

[0080] According to example implementations, receiving the second request at the second physical request interface involves receiving the second request from a baseboard management controller. A particular advantage is that a security processor can be used in relatively complex computer architectures where multiple requesters can utilize the security processor concurrently.

[0081] In accordance with example implementations, a first set of requests can be received through the first physical request interface, and at least one of the operating system or firmware runtime instructions can be executed to generate this first set of requests. A second set of requests can be received through the second physical request interface, and firmware instructions can be executed on a management controller to generate this second set of requests. A particular advantage is that a single security processor can be used in relatively complex computer architectures where multiple requesters can utilize the security processor concurrently.

[0082] According to example implementations, executing firmware instructions on the management controller involves executing firmware commands on at least one baseboard management controller or an intelligent input / output (I / O) processor. A particular advantage is that a security processor can be used in relatively complex computer architectures where multiple requesters can utilize the security processor concurrently.

[0083] In accordance with example implementations, the use of the first physical request interface and / or the second physical request interface is configured in response to the computer platform's startup. This configuration can be locked. A particular advantage is that a multi-interface security processor can be configured by the boot service firmware.

[0084] In accordance with example implementations, the security processor responds to a request with a data entry representing the configuration. A particular advantage is that users of the security processor can be informed about its configuration.

[0085] According to implementation examples, the configuration involves using the first physical request interface and / or the second physical request interface for a corresponding hierarchy of a multitude of security processor hierarchies. A particular advantage is that different configuration policies can be defined for different corresponding security processor hierarchies.

[0086] In accordance with example implementations, a security processor resource can be shared between the first and second physical request interfaces. This sharing can involve the security processor allowing one access per access type across both the first and second physical request interfaces; allowing one access per access type across either the first or second physical request interface; and preventing one access per access type across both the first and second physical request interfaces. A key advantage is the ability to control access rights for different requesters independently.

[0087] In accordance with example implementations, resource sharing also includes sharing a measurement register of the safety processor. The first access type corresponds to a command to read the contents of the measurement register. The second access type corresponds to a command to extend the contents of the measurement register. A particular advantage is that a specific measurement register can be extended by a management controller and cannot be extended by other requesters of the safety processor.

[0088] In accordance with example implementations, resource sharing involves sharing a measurement register of the safety processor and allowing a baseboard management controller to extend the management register to include an initial boot block measurement. A key advantage is that a specific measurement register can be extended by a baseboard management controller and is not extended by other safety processor requesters.

[0089] According to example implementations, the security processor controls access to a security object based on a match between the permissions received via the multiple physical request interfaces. A particular advantage is that access to certain security objects can be controlled independently of multiple requesters.

[0090] Although the present disclosure has been described with respect to a limited number of implementations, those skilled in the art who have the advantages of this disclosure will appreciate numerous modifications and variations thereof. It is intended that the appended claims cover all such modifications and variations.

Claims

[1] A procedure comprising the following: Communicating a first tenant from a plurality of tenants with a security processor (160) of a computer platform (100) via a first physical request interface (822) of the security processor (160) to acquire ownership of a first instruction execution machine (826) of the security processor (160) connected to the first physical request interface (822); Communicating a second tenant from the plurality of tenants with the security processor (160) via a second physical request interface (824) of the security processor (160) to acquire ownership of a second instruction execution machine (828) of the security processor (160) connected to the second physical request interface (824); Receiving with the security processor (160) a first request (808) from the first tenant in the first physical request interface (822); Receiving with the security processor (160) a second request (816) from the second tenant in the second physical request interface (824); and Processing the first request (808) with the first instruction execution engine (826) and processing the second request (816) with the second instruction execution engine (826) to perform appropriate trusted computational operations. [2] The method according to claim 1, wherein: The reception of the first request (808) at the first physical request interface (822) includes the reception of the first request (808) from a main processing core (110) of the computer system (100); and The reception of the second request (816) at the second physical request interface (824) includes the reception of the second request (816) from a unit of the computer system (100) other than the main processing core (110). [3] The method according to claim 2, wherein receiving the second request (816) in the second physical request interface (824) comprises receiving the second request (816) from a baseboard management controller (812). [4] The method according to claim 1, which further comprises: Receiving an initial set of requests at the first physical request interface (822), wherein the initial set of requests includes the first request (808); Executing at least operating system instructions or firmware runtime instructions to generate the initial set of requests; Receiving a second set of requirements in the second physical request interface (824), wherein the second set of requirements includes the second requirement (816); and Executing firmware instructions on a management controller (230) to generate the second set of requests. [5] The method according to claim 4, wherein executing the firmware instructions on the management controller (230) comprises executing firmware instructions on at least one of a baseboard management controller (812) or an intelligent input / output (I / O) processor. [6] The method according to claim 1, which further comprises: Configure the use of the first physical request interface (822) and / or the second physical request interface (824) in response to the startup of the computer system (100); and Locking the configuration. [7] The method according to claim 6, which further comprises: The security processor (160) provides a response with data representing the configuration in response to a request. [8] The method according to claim 6, wherein the configuration comprises: Configuring the use of at least one of the first physical request interfaces (822) or the second physical request interface (824) for a corresponding hierarchy of a plurality of hierarchies of the security processor (160). [9] The method of claim 1, which further comprises: Sharing a resource of the security processor (160) between the first physical request interface (822) and the second physical request interface (824), wherein the sharing includes that: the security processor (160) allows first access according to a first access type via the first physical request interface (822) and the second physical request interface (824); the security processor (160) allows a second access according to a second access type via one of the first physical request interfaces (822) and the second physical request interface (824); and the security processor (160) prevents a third access corresponding to the second access type, via the other of the first physical request interface (822) and the second physical request interface (824). [10] The method according to claim 9, wherein: the sharing of the resource further includes the sharing of a measurement register of the security processor (160); the first access type corresponds to a command to read the contents of the measurement register; and The second access type corresponds to a command to extend the contents of the measurement register. [11] The method of claim 9, comprising the sharing of the resource: a shared use of a measurement register of the security processor (160); and that it enables a baseboard management controller (812) to extend the measurement register to include an initial integrity measurement. [12] The method according to claim 9, wherein the sharing of the resource comprises the sharing of another memory of the shared security processor (160) as a memory for storing a measurement. [13] The method according to claim 1, which further comprises: The security processor (160) controls access to a security object depending on a match of the permissions received via the multiple physical request interfaces (822, 824). [14] A security processor (160) comprising the following: multiple physical command-response input / output (I / O) interfaces (164) comprising a first physical command I / O interface (704) and a second physical command I / O interface (708); a first execution processor (718) for processing instructions (706) provided by a first owner of the first execution processor (718) and received at the first physical I / O interface (704) to perform cryptographic processing operations; a second execution processor (722) for processing instructions (710) provided by a second owner of the second execution processor (722) and received in the second physical I / O interface (708) to perform cryptographic processing operations; and an administrative processor (714) for the enforcement of a first right of ownership corresponding to the first owner and for the enforcement of a second right of ownership corresponding to the second owner. [15] The security processor (160) according to claim 14, further comprising a shared resource, wherein the management processor (714): for the first owner, first access to the shared resource according to a first access type; for the second owner a second access to the shared resource corresponding to the first access type; for the first owner a third access to the shared resource according to a second access type; and This prevents the second owner from having a fourth access to the shared resource, which corresponds to the second access type. [16] The security processor (160) according to claim 15, wherein: the shared resource includes a platform configuration register; The first access includes access to read content from the platform configuration register; the second access includes access to read the contents of the platform configuration register; the third access includes access to extend the content of the platform configuration register; and The fourth access includes access to extend the content of the platform configuration register. [17] A computer system (100), comprising: at least one processing core (110) to make initial requests (808) for initial trusted computational operations; a baseboard management controller (812) to provide second requests (816) for second trusted computational operations; and a security processor (160) with: a plurality of execution machines (826, 828) to perform the first and second trusted computational operations in response to the first requirements (808) and the second requirements (816), wherein the plurality of execution machines (826, 828) comprises a first execution machine and a second execution machine; and a variety of physical interfaces (822, 824), which include the following: a first physical interface (822) connected to the first execution machine (826) to receive the first requests (808); and a second physical interface (824) connected to the second execution machine (828) to receive the second requests (816). [18] The computer system (100) according to claim 17, wherein the at least one processing core (110) executes firmware to start the computer system (100) and to control the activation of the second physical interface (824). [19] The computer system (100) according to claim 17, wherein the at least one processing core (110) executes UEFI (Unified Extensible Firmware Interface) instructions and operating system instructions to provide the first requirements (808). [20] The computer system (100) according to claim 17, wherein the security processor (160) comprises a trusted platform module (TPM).

Images