Static Configuration of the Security Mode of the Accelerator Card

Abstract

The accelerator card may include a read-only memory configured to store a security identifier in a designated field within the read-only memory, and a satellite controller configured to read the security identifier in response to a reset event, the satellite controller configured to select a security mode from a plurality of security modes based on the security identifier, and to implement the selected security mode within the accelerator card.

Description

Technical Field

[0001] The present disclosure relates to using peripheral devices with a computer system, and more particularly to configuring a security mode for an accelerator card type of peripheral device.

Background Art

[0002] Hardware acceleration refers to a technique in which tasks of a computing system are offloaded from a central processing unit (CPU) to other hardware within the system. The other hardware can be specially tuned or adapted to execute the offloaded tasks. The hardware to which the tasks are offloaded may be referred to as an accelerator card.

[0003] An accelerator card is communicably linked to a computer system via a communication bus. Often, an accelerator card has an edge connector that fits into an available bus slot of the computer system. Additionally, an accelerator card can be communicably linked to a computer system by any of a variety of different communication buses or other communication technologies.

Summary of the Invention

[0004] An accelerator card can include a read-only memory configured to store a security identifier within a specified field in the read-only memory, and a satellite controller configured to read the security identifier in response to a reset event. The satellite controller can select a security mode from a plurality of security modes based on the security identifier and implement the selected security mode within the accelerator card.

[0005] A method of configuring a security mode for an accelerator card may include using a satellite controller of the accelerator card to read a security identifier from a specified field of a read-only memory of the accelerator card in response to a reset event, selecting a security mode from a plurality of security modes for the accelerator card based on the security identifier and using the satellite controller, and implementing the selected security mode within the accelerator card.

[0006] This summary section of the invention is provided only to introduce certain concepts and is not intended to identify key or essential features of the claimed subject matter. Other features of the invention's configuration will become apparent from the accompanying drawings and the following detailed description.

[0007] The configuration of the present invention is shown by way of example in the accompanying drawings. However, the drawings should not be construed as limiting the configuration of the present invention to only the specific implementations shown. Various aspects and advantages will become apparent upon review of the following detailed description and with reference to the drawings.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

[0009] The present disclosure is concluded by the claims that define the novel features, but the various features described within the present disclosure are thought to be better understood by considering the description in conjunction with the drawings. The processes, machines, manufactures, and any variations thereof described herein are provided for purposes of illustration. The specific structural and functional details described within the present disclosure should not be construed as limitations, but rather as a representative basis for teaching one of ordinary skill in the art to variously employ the features described in any suitable detailed structure as a basis for the claims and in fact. Further, the terms and phrases used within the present disclosure are not intended to be limiting, but rather are intended to provide an understandable description of the features described.

[0010] The present disclosure relates to using peripheral devices with a computer system, and more particularly to configuring a security mode for an accelerator card type of peripheral device. Modern computer systems can utilize a peripheral device often referred to as an accelerator card to obtain one or more benefits that may not be achievable relying only on the central processing unit (CPU) of the computer system. These benefits can include, but are not limited to, faster computations, reduced power consumption, and redundancy.

[0011] The root of trust refers to a set of functions provided by trusted components of a computer system that are always trusted by the operating system of the computer system. A computer system can extend the root of trust to specific peripheral devices such as an accelerator card. However, different computer systems may utilize different roots of trust, and each different root of trust may have a different path for extending the root of trust to a peripheral device.

[0012] According to the configuration of the present invention described within the present disclosure, a peripheral device such as an accelerator card can automatically detect the security role required for the peripheral device. For example, in response to a reset event, the peripheral device can automatically determine the security mode to be implemented within the peripheral device. The security mode to be implemented may depend on the root of trust of a specific host computer in which the peripheral device is used.

[0013] In one aspect, the peripheral device can select a security mode from a plurality of security modes based on a security identifier stored in the memory of the peripheral device. The security identifier indicates the root of trust of the host computer. The peripheral device can automatically configure itself by implementing the selected security mode. By implementing the selected security mode, the peripheral device can respond to the root of trust of the host computer via the correct path, execute any necessary security protocols, and subsequently start one or more application workloads following the execution of such security protocols.

[0014] In an exemplary implementation, the peripheral device is statically configured in the selected security mode. The static configuration of the security mode means that the peripheral device selects and implements the security mode in response to a reset event. The reset event may include, for example, a peripheral device that executes a boot process. For example, in response to being powered on or reset, the peripheral device can select a security mode and implement that security mode.

[0015] Further aspects of the configuration of the present invention will be described in more detail below with reference to the figures. For the sake of simplicity and clarity of illustration, the elements shown in the figures are not necessarily drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, reference numerals may be repeated between figures to indicate corresponding, similar, or like features where appropriate.

[0016] FIG. 1 shows an exemplary computing environment 100 for use with the configuration of the present invention described within the present disclosure. The computing environment includes a host computer 102 coupled to an accelerator card 104. The accelerator card 104 is an example of a peripheral device of the host computer 102.

[0017] The components of computer 102 may include, but are not limited to, a host processor 106 (e.g., one or more CPUs), a memory 108, and a bus 110 that couples various system components including the memory 108 to the host processor 106. The host processor 106 may be implemented as any of a variety of processors capable of executing program code. Exemplary processor types include, but are not limited to, processors having an x86-type architecture (IA-32, IA-64, etc.), a Power architecture, and an ARM processor.

[0018] The processor 106 communicates with the memory 108 via the bus 110. For example, the bus 110 may be implemented as a memory bus. The computer 102 typically includes a variety of computer-readable media. Such media can be any of a variety of media accessible by the host computer 102 and can include any combination of volatile media, non-volatile media, removable media, and / or non-removable media.

[0019] Memory 108 is an example of at least one computer program product having a set (e.g., at least one) of program modules (e.g., program code) configured to execute functions and / or operations described within the present disclosure in relation to host processor 106. For example, memory 108 may include computer-readable media in the form of volatile memory such as random access memory (RAM) 112 and / or cache memory 114. Computer 102 may also include other removable / non-removable, volatile / non-volatile computer system storage media. For example, storage system 116 may include a disk drive that is capable of reading from and writing to non-removable non-volatile magnetic media and / or solid state media (e.g., a “hard drive”) contained therein. Storage system 116 may also include one or more disk drives for reading from and writing to removable non-volatile media that may be magnetic, solid state, and / or optical. The disk drive may be connected to bus 110 by one or more data media interfaces.

[0020] Program / utility 118 may include one or more program modules 120. Program modules 120 stored in memory 108 may include, but are not limited to, an operating system, one or more application programs (e.g., user applications), other program modules, and / or program data. Program modules 120 generally execute functions and / or methodologies as described herein with respect to at least operations performed by host processor 106.

[0021] Program / Utility 118 is executable by host processor 106. Any data items used, generated, and / or operated on by Program / Utility 118 and host processor 106 are functional data structures that impart functionality when employed by host processor 106. As defined within this disclosure, a "data structure" is the physical implementation of the organization of data of a data model within physical memory. Thus, a data structure is formed from specific electrical or magnetic structural elements within memory. A data structure imposes a physical organization on data stored within memory for use by application programs executed using a processor.

[0022] Host computer 102 may include one or more input / output (I / O) interfaces 122 communicatively linked to host processor 106 via bus 124. Bus 124 may be an expansion bus or an I / O bus. I / O interface 122 enables computer 102 to couple to and communicate with various peripheral devices such as accelerator card 104. Host computer 102 may be coupled to other devices (not shown), such as a keyboard, a pointing device, and / or a display, via other I / O interfaces. Examples of I / O interface 122 may include, but are not limited to, network cards, modems, network adapters, hardware controllers, and the like.

[0023] Bus 124 may be implemented as any of a variety of communication bus structures. By way of example and not limitation, such bus structures may include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, Peripheral Component Interconnect (PCI) bus, or PCI Express (PCIe) bus.

[0024] In the example of FIG. 1, host computer 102 is coupled to accelerator card 104 via communication channel 126. Communication channel 126 can be established by I / O interface 122 on bus 124. In an exemplary implementation, I / O interface 122 for host computer 102 to communicate with accelerator card 104 is a PCIe adapter. Accelerator card 104 can be implemented as a circuit board coupled to host computer 102. Accelerator card 104 can be inserted, for example, into an available card slot of host computer 102, such as an available bus and / or PCIe slot. In the example of FIG. 1, communication channel 126 is an "in-band" communication channel.

[0025] In one or more exemplary implementations where host computer 102 includes a baseboard management controller (BMC) (not shown), host computer 102 can also be communicatively linked to accelerator card 104 by communication channel 128. Communication channel 128 can be implemented as an out-of-band (OOB) communication channel that communicatively links the BMC to accelerator card 104. In one aspect, communication channel 128 can be implemented via the same physical connector as communication channel 126. Still, communication channel 128 is physically separate from and isolated from communication channel 126.

[0026] In the example of FIG. 1, the accelerator card 104 includes a programmable IC 132. The programmable IC 132 includes programmable circuitry (e.g., programmable logic). Although not explicitly shown, it should be understood that the programmable IC 132 may include one or more hardwired circuit blocks that can be used to cooperate with the programmable circuitry. As an example, the programmable IC 132 may be implemented as a field programmable gate array (FPGA). In one aspect, the programmable IC 132 may be implemented as a system on chip (SoC) that includes different subsystems that can operate in cooperation with each other. For example, the programmable IC 132 may include a processor and / or a processor array subsystem, a programmable logic subsystem, and / or one or more other dedicated hardwired circuit blocks. The accelerator card 104 may also include other components not shown in FIG. 1 that are coupled to the programmable IC 132, such as volatile memory and / or non-volatile memory.

[0027] FIG. 1 is not intended to suggest any limitation as to the scope of use or functionality of the examples described herein. The host computer 102 is an example of computer hardware (e.g., a system) that can perform various operations described within this disclosure in relation to the accelerator card 104 and / or the programmable IC 132. The accelerator card 104 is provided for illustrative purposes and is not intended to limit the configuration of the present invention. A more detailed example of the accelerator card 104 is described in relation to FIG. 2.

[0028] In one aspect, host computer 102 represents a server. For example, host computer 102 can be implemented as a stand-alone device, as a bare metal server, or as part of a cluster of computing devices. In another aspect, computing environment 100 can represent a data center in which host computer 102 is implemented within computing environment 100. A data center refers to a dedicated space such as a room or building that houses computing facilities such as, for example, servers, routers, switches, firewalls, telecommunications equipment, and / or storage systems. Data centers often include support components such as backup equipment, fire suppression, and air conditioning. A data center can be private or shared. Typically, access to computing hardware in a data center is restricted to authorized personnel only. In one exemplary implementation, computing environment 100 can represent a hyperscale data center.

[0029] In an exemplary implementation, computer environment 102 can represent a distributed cloud computing environment in which host computer 102 is implemented within computer environment 102. In a distributed cloud computing environment, tasks are executed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules can be located on both local and remote computer system storage media including memory storage devices.

[0030] As used herein, the term "cloud computing" refers to a computing model that facilitates convenient on-demand network access to a shared pool of configurable computing resources such as networks, servers, storage devices, applications, ICs (e.g., programmable ICs), and / or services. These computing resources can be rapidly provisioned and released with minimal management effort or interaction with a service provider. Cloud computing can be characterized by enhanced availability, on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.

[0031] For example, several computing environments such as cloud computing environments, edge computing environments, and / or data centers generally support a field programmable gate array as a service (FaaS) model. In the FaaS model, user functions are hardware accelerated as circuit designs implemented within a programmable IC operating under the control of a host computer. Other examples of cloud computing models are described by the National Institute of Standards and Technology (NIST), more specifically, by NIST's Information Technology Laboratory.

[0032] It should be understood that an actual data center and / or a distributed cloud computing environment may include more computers than are illustrated, and one or more or all of the computers may have one or more accelerator cards coupled thereto.

[0033] In an exemplary implementation, the accelerator card 104 can automatically and statically configure a security mode within the accelerator card 104. The accelerator card 104 can implement a security mode that is compatible with the root-of-trust infrastructure provided by the host computer 102. Thereby, the accelerator card 104 can interact with the root-of-trust of the host computer 102 via the correct signal path.

[0034] FIG. 2 shows another example of a computing environment 100 that includes a host computer 102 and an accelerator card 104. The accelerator card 104 includes, in addition to the programmable IC 132, a satellite controller 202 coupled to a switch 204, a programmable read-only memory (PROM) 206, and a control circuit 208. In one example, the satellite controller 202 can be implemented as a processor that can execute program code. In another example, the satellite controller 202 can be implemented as a dedicated circuit.

[0035] The accelerator card 104 can also include a random access memory (not shown) coupled to the programmable IC 132. The satellite controller 202 can be coupled to a port of the switch 204 via a serial peripheral interface (SPI) included therein. The satellite controller 202 can also communicate with the control circuit 208 via an inter-integrated circuit (I2C) interface included therein, provide control signals to the control circuit, and read from the PROM 206. It should be understood that the specific buses, communication channels, and / or interfaces described herein that are used by the components of the accelerator card 104 are provided for purposes of illustration and not limitation. Equivalent and / or suitable interfaces other than those described may be used.

[0036] In the example of FIG. 2, host computer 102 includes BMC 210. For example, FIG. 2 may show the motherboard of host computer 102 or a portion of the motherboard. In this example, BMC 210 may be implemented on the motherboard of the same host computer 102 as host processor 106. For purposes of illustration, the other components of host computer 102 described above in connection with FIG. 1 are not shown in FIG. 2. Host processor 106 is coupled to programmable IC 132 via communication channel 126. Communication channel 126 extends through connector 212. Connector 212 may be a PCIe connector. BMC 210 is coupled to satellite controller 202 via communication channel 128. Communication channel 128 also extends through connector 212. In one aspect, communication channel 128 is implemented as a system management bus (SMBus).

[0037] In an exemplary implementation, PROM 206 may be implemented as an electrically erasable PROM. PROM 206 may contain various data that is stored therein when accelerator card 104 is manufactured and before it is sold in the field. This data may include field replaceable unit (FRU) data. The FRU data may include other equipment manufacturer (OEM) data. In an exemplary implementation, a security identifier (ID) may be stored within the FRU OEM data, such as in an FRU EOM field, for example.

[0038] In an exemplary implementation, the security ID identifies the root of trust of the accelerator card and thus a specific path for extending the root of trust. For illustrative purposes, the security ID may identify a first value, i.e., an in-band (IB) security mode, to be implemented within the accelerator card 104. In the IB security mode, the root of trust is the host processor 106. In the IB security mode, the path enabled to extend the root of trust is communication channel 126, which is an IB communication channel. Alternatively, the security ID may identify one or more other values, i.e., an out-of-band (OOB) security mode, to be implemented within the accelerator card 104. In the OOB security mode, the root of trust is the BMC 210. In the OOB security mode, the path enabled to extend the root of trust is communication channel 128, which is an OOB communication channel. In the example described herein, the IB channel is used by the host processor 106 to communicate with the accelerator card 104, e.g., to offload tasks from the host computer 102 to the acceleration card 104 for purposes of, for example, executing a workload. The OOB communication channel is not used by the accelerator card 104 to execute a workload from the host computer 102.

[0039] Switch 204 is coupled to memory 214. Memory 214 can be implemented as non-volatile memory. In the example of FIG. 2, memory 214 includes configuration memory 216 and recovery configuration memory 218. Configuration memory 216 can be a primary configuration memory in that programmable IC 132 boots from configuration memory 216. Recovery configuration memory 218 can be used as a backup of configuration memory 216 in certain situations. In one aspect, configuration memory 216 and recovery configuration memory 218 can each be implemented as flash memory. Memory 214 can store, for example, configuration data of programmable IC 132. Switch 204 is configurable by control signals provided by control circuit 208 and provides either read-only access to configuration memory 216 or read and write access to configuration memory 216 to programmable IC 132 based on a security mode implemented within accelerator card 104. When switch 204 provides read and write access to configuration memory 216 to programmable IC 132, switch 204 prohibits or turns off access to memory 214 by satellite controller 202.

[0040] In this example, programmable IC 132 includes interface 222 connected to a port of switch 204, thereby enabling reading from memory 214 of programmable IC 132 or reading and writing to configuration memory 216. In an exemplary implementation, interface 222 is a Quad Serial Peripheral Interface (QSPI). Switch 204 may be configured such that programmable IC 132 can read from recovery configuration memory 218 regardless of a particular security mode implemented on accelerator card 104. In one or more exemplary implementations, depending on the configuration of switch 204 via control circuit 208, programmable IC 132 can read and / or write to one or both of memories 214.

[0041] In response to a reset event of the accelerator card 104, the satellite controller 202 reads the security ID from the PROM 206. The reset event can be any occurrence of restart and / or boot of the accelerator card and the satellite controller therein. Examples of reset events can include a hard reset where the power of the accelerator card 104 is turned off and then on, a soft reset of the accelerator card 104, and an initial power-on of the accelerator card 104.

[0042] Based on the value of the security ID, the satellite controller 202 sends a command to the control circuit 208 to configure the switch 204 in a specific configuration. For example, if the security ID indicates an IB security mode where the root of trust is the host processor 106, the satellite controller 202 instructs the control circuit 208 to configure the switch 204 to provide read and write access to the configuration memory 216 to the programmable IC 132. The satellite controller 202 further instructs the control circuit 208 to configure the switch 204 to prevent the satellite controller 202 from accessing the memory 214. In that case, the switch 204 effectively disconnects the satellite controller 202 from the memory 214. In response to receiving the command from the satellite controller 202, the control circuit 208 generates the control signals necessary to configure the switch 204 as described.

[0043] In the IB security mode, the programmable IC 132 is given read and write access to the configuration memory 216. Thus, the programmable IC 132 can, at least initially, boot using a boot image read from the configuration memory 216. Within the present disclosure, the boot image of the programmable IC 132 may be referred to at any time as the "firmware" of the programmable IC 132. Once the boot image is loaded into the programmable IC 132, it may implement a secure circuit design 220 within the programmable IC 132. The secure circuit design 220 can communicate with the host processor 106 via the communication channel 126. For example, the secure circuit design 220 may implement a communication interface such as a PCIe endpoint within the programmable IC 132. The secure circuit design 220 can respond to further instructions received from the host processor 106 regarding the implementation of security protocols within the programmable IC 132 and / or the accelerator card 104.

[0044] In the case of the IB security mode, the secure circuit design 220 can distinguish between the access rights of user applications running on the host processor 106 and the root of trust (operating system) running on the host processor 106. The secure circuit design 220 can authenticate additional configuration data that can be received, for example, from the host processor 106 functioning as the root of trust. For example, the secure circuit design 220 can receive a different boot image from the host processor 106 functioning as the root of trust. In response to receiving a boot image for configuring the programmable IC 132, the secure circuit design 220 can authenticate the boot image. For example, the secure circuit design 220 can generate a hash value of the received boot image and compare the hash value with a known or predetermined hash value. The secure circuit design 220 can write the authenticated configuration data or boot image to the configuration memory 216. Thus, the secure circuit design 220 operating under the control of the host processor 106 can update the configuration memory 216 with the configuration data received from the host processor 106. By giving the secure circuit design 220 the right to write to the configuration memory 216, the root of trust is extended from the host processor 106 to the secure circuit design 220.

[0045] In the IB security mode, the satellite controller 202 does not communicate with the BMC 210 via the communication channel 128. That is, the satellite controller 202 can be placed in a mode where it does not respond to commands or communications received from the BMC 210 via the communication channel 128. In the IB security mode, the satellite controller 202 is effectively disconnected from the programmable IC 132 and / or the memory 214 until at least the next reset event of the accelerator card 104.

[0046] When the security ID indicates an OOB security mode where the root of trust is the BMC 210, the satellite controller 202 instructs the control circuit 208 to configure the switch 204 to provide the programmable IC 132 with read-only access to the configuration memory 216. The satellite controller 202 further instructs the control circuit 208 to configure the switch 204 to provide the satellite controller 202 with read and write access to the configuration memory 216. In response to receiving the instruction from the satellite controller 202, the control circuit 208 generates the control signals necessary to configure the switch 204 as described. In one or more exemplary implementations, depending on the configuration of the switch 204 via the control circuit 208, the satellite controller 202 can read and / or write to one or both of the memories 214.

[0047] In the OOB security mode, the programmable IC 132 is given read-only access to the configuration memory 216. Thus, the programmable IC 132 can initially boot using, at least, the boot image read from the configuration memory 216. Once the boot image is loaded into the programmable IC 132, a secure circuit design 220 can be implemented within the programmable IC 132. It should be understood that the specific implementation of the secure circuit design 220 can differ between the IB security mode and the OOB security mode. That is, a different secure circuit design than that for the OOB security mode can be stored in the configuration memory 216, read therefrom, and implemented within the programmable IC 132 for the IB security mode. As an example, in the case of the IB security mode, the secure circuit design 220 can execute authentication of specific configuration data received from the host processor 106 and write the authenticated configuration data to the configuration memory 216, whereas the secure circuit design 220 may not be able to perform such a function in the case of the OOB security mode.

[0048] In the OOB security mode, the satellite controller 202 communicates with the BMC 210 via the communication channel 128. That is, the satellite controller 202 is placed in a mode where it responds to commands or communications received from the BMC 210, which is the root of trust, via the communication channel 128. The satellite controller 202 can respond to further instructions received from the BMC 210 regarding the implementation of the security protocol within the programmable IC 132 and / or the accelerator card 104.

[0049] In one aspect, the OOB security mode means that the satellite controller 202 is first authenticated by the BMC 210. Once authenticated by the BMC 210, the satellite controller 202 can authenticate further configuration data that can be received from the BMC 210, which functions as the root of trust. For example, the satellite controller 202 can receive another boot image of the programmable IC 132 from the BMC 210, which functions as the root of trust. When the satellite controller 202 receives the boot image, it can authenticate the boot image. For example, the satellite controller 202 can generate a hash value from the received boot image and compare it with a known or predetermined hash value. The satellite controller 202 can write the authenticated configuration data or boot image to the configuration memory 216. Thus, the programmable IC 132 does not execute the authentication of the boot image or write such data to the configuration memory 216. By giving the secure satellite controller 202 the write permission to the configuration memory 216, the root of trust is extended from the BMC 210 to the satellite controller 202.

[0050] In one or more exemplary implementations, the OOB security mode may implement specific routines for configuring the accelerator card 104 based on a particular customer or user who uses the accelerator card 104. For example, a security ID may identify a particular security mode and may also identify a particular set of routines to be executed by the satellite controller 202. As an example, the security ID may include one or more least significant bits that indicate a particular entity that will use the accelerator card 104. The routines to be executed may be specific to a particular user of the accelerator card 104.

[0051] As an example, the satellite controller 202 may use the accelerator card 104 to execute specific routines that are specific to a particular hyperscale vendor. The satellite controller 202 may include a plurality of routines that correspond to a plurality of different hyperscale vendors. A plurality of different security IDs may indicate the OOB security mode, and each such different security ID corresponds to a different vendor. When the security ID is read and the OOB security mode is implemented, the satellite controller 202 can execute only those security routines associated with the security ID, for example, a selected one of the plurality of routines. For example, only these security routines corresponding to the hyperscale vendor indicated by the security ID are executed or implemented by the satellite controller 202.

[0052] In the example of FIG. 2, the secure circuit design 220 can be regarded as the "golden" or trusted circuit design used to boot the programmable IC 132. The secure circuit design 220 enables either the host processor 106 or the BMC 210 to execute the remaining configuration. As described above, a particular version or implementation of the secure circuit design 220 can vary based on the particular security mode implemented by the accelerator card 104. The secure circuit design 220 can be updated by the root of trust when the accelerator card 104 is shipped to the field.

[0053] When the programmable IC 132 boots with the secure circuit design 220 implemented therein and security-related instructions from the root of trust are executed, the programmable IC 132 reaches a known good state. At that point, application configuration data implementing the user-specific circuit 224 therein can be loaded into the programmable IC 132, regardless of the particular security mode implemented. The application configuration data is distinct from the boot image received from the root of trust. When the user-specific circuit 224 is implemented within the programmable IC 132, the application configuration data and data operating as part of executing the workload are provided from the host processor 106 via the communication channel 126.

[0054] The examples described within this disclosure enable the same accelerator card to be used within different computing environments. For example, the accelerator card 104 may simply have a specific secure ID loaded during manufacturing to support an OEM type of framework that uses the IB security mode or a hyperscale type of framework that uses the OOB security mode. When the IB security mode is implemented, the host computer may or may not have, for example, a BMC. The configuration of the present invention described herein enables one model of the accelerator card to support two different root-of-trust frameworks. There is no need to create two different physical implementations of the accelerator card 104 to support the different root-of-trust frameworks described.

[0055] Figure 3 shows an exemplary method 300 of static configuration of security modes in an accelerator card. The accelerator card may be implemented as described in connection with FIGS. 1 and 2.

[0056] In block 302, the accelerator card 104 is powered on or reset in response to a reset event. In response to the power-on or reset of the accelerator card 104, the satellite controller 202 boots. In block 304, the satellite controller 202 reads the security ID from a designated or predetermined memory location within the PROM 206. The security ID may be stored within the PROM 206 during the manufacture of the accelerator card 104.

[0057] As described above, the security ID indicates which of the IB security mode or the OOB security mode should be implemented by the accelerator card 104. The IB security mode recognizes a certain entity, for example, the host processor 106, as the root of trust. The OOB security mode recognizes another entity, for example, the BMC 210, as the root of trust. Each different root of trust utilizes a different signal path or framework to extend the root of trust.

[0058] In block 306, the satellite controller 202 determines the specific security mode to be implemented within the accelerator card 104 based on the security ID read from the PROM 206. The security ID indicates, for example, either the IB security mode or the OOB security mode. As described above, the security ID can also identify a specific set of security protocols or operations to be executed by the satellite controller 202 in the case of the OOB security mode. In response to determining that the security ID indicates the IB security mode in block 308, method 300 proceeds to block 310. In response to determining that the security ID indicates the OOB security mode in block 308, method 300 proceeds to block 320.

[0059] Following block 310, the satellite controller 202 provides instructions to the control circuit 208 for configuring the switch 204. In block 312, the control circuit 208 provides a control signal to the switch 204 in response to the instructions from the satellite controller 202 to configure the switch 204, thereby providing read and write access to the configuration memory 216 for the programmable IC 132 and disconnecting the satellite controller 202 from the configuration memory 216 and the backup configuration memory 218. For example, the switch 204 can be configured to disable the port to which the satellite controller 202 is connected.

[0060] In block 314, the programmable IC 132 is booted by the secure circuit design 220 as read from the configuration memory 216. That is, the programmable IC 132 reads a boot image for the secure circuit design 220 from the configuration memory 216, loads it into the programmable IC 132, and thereby implements the secure circuit design 220. In block 316, the secure circuit design 220 enters a mode in which it responds to commands received from the host processor 106 as a root of trust. The secure circuit design 220 may implement, for example, a communication endpoint for communicating with the host processor 106 via the communication channel 126. The secure circuit design 220 can receive, via the channel 126, commands from the host processor 106 that provide a boot image, instructions for authenticating the boot image, and instructions for storing the authenticated boot image in the configuration memory 216. The secure circuit design 220 can further configure the programmable IC 132 and / or other components of the accelerator card 104 to implement other security measures and / or protocols therein in response to commands received from the host processor 106 via the communication channel 126.

[0061] In block 318, the host processor 106 can load application configuration data into the programmable IC 132 via the communication channel 126. When loaded, the application configuration data implements the user-specific circuit 224 within the programmable IC 132. The application configuration data is loaded into the programmable IC 132, for example, following the implementation of any security protocols and / or measurements within the programmable IC 132 when the security configuration is complete. Using the user-specific circuit 224 implemented within the programmable IC 132, the host processor 106 can send data to the programmable IC 132 to operate as part of the workload executed by the user-specific circuit 224.

[0062] Following block 320, the satellite controller 202 provides instructions to the control circuit 208 to configure the switch 204. In block 322, in response to the instructions from the satellite controller 202, the control circuit 208 provides a control signal to the switch 204 to configure the switch 204, thereby providing read-only access to the configuration memory 216 in the programmable IC 132 and providing read and write access to the configuration memory 216 to the satellite controller 202.

[0063] In block 324, the satellite controller 202 enters a mode in response to a command received from the BMC 210. The BMC 210 can communicate with the satellite controller 202 via, for example, the communication channel 128. The satellite controller 202 can receive, via the channel 128, commands from the BMC 210 that provide a boot image, instructions to authenticate the boot image, and instructions to store the authenticated boot image in the configuration memory 216. The satellite controller 202 can further implement other security measures and / or protocols therein in response to commands received from the BMC 210 via the communication channel 128.

[0064] In block 326, the programmable IC 132 boots with the secure circuit design 220 as read from the configuration memory 216. That is, the programmable IC 132 reads a boot image for the secure circuit design 220 from the configuration memory 216, loads it into the programmable IC 132, thereby implementing the secure circuit design 220.

[0065] After block 326, method 300 can proceed to block 318, where the user-specific circuit 224 can be implemented within the programmable IC 132 under the control of the host processor 106, and the user-specific circuit 224 can execute the workload as described.

[0066] Figure 4 shows another exemplary method 400 of the static configuration of the security mode in the accelerator card. The accelerator card can be implemented as described in connection with FIGS. 1 and 2.

[0067] In block 402, the satellite controller reads a security identifier from a specified field of the read-only memory of the accelerator card in response to a reset event. In block 404, based on the security identifier, the satellite controller selects a security mode from a plurality of security modes for the accelerator card. In block 406, the selected security mode is implemented within the accelerator card.

[0068] Each of the foregoing and other implementations may optionally include one or more of the following features, either alone or in combination. Some exemplary implementations include all of the following features in combination.

[0069] In one aspect, the plurality of security modes includes an IB security mode and an OOB security mode.

[0070] The method may include designating a host processor of a host computer communicating with the accelerator card as a root of trust of the accelerator card in response to implementing the IB security mode.

[0071] The accelerator card may include a programmable IC and configuration memory for the programmable IC.

[0072] The method may include enabling an IB communication channel between the host processor and the programmable IC for receiving a boot image in response to implementing the IB security mode. The programmable IC is configured to authenticate the boot image and store the boot image in the configuration memory.

[0073] The method may include designating the BMC of the host computer as the root of trust of the accelerator card in response to implementing the OOB security mode.

[0074] The method may include enabling an OOB communication channel between the satellite controller and the BMC for receiving a boot image in response to implementing the OOB security mode. The satellite controller may be configured to authenticate the boot image and store the boot image in the configuration memory.

[0075] The accelerator card may include a configuration memory, a programmable IC, and a switch coupled to the satellite controller, and the switch may be configured by the satellite controller to provide write access to the configuration memory to the programmable IC or the satellite controller based on a selected security mode.

[0076] The method may include configuring the switch to provide read and write access to the configuration memory to the programmable IC and disconnect the satellite controller from the configuration memory in response to implementing the IB security mode.

[0077] The method may include configuring the switch to provide read-only access to the configuration memory to the programmable IC and provide read and write access to the configuration memory to the satellite controller in response to implementing the OOB security mode.

[0078] In another aspect, the read-only memory may have a security identifier pre-loaded and be readable only by the satellite controller.

[0079] In one or more exemplary implementations, the IB security mode can be used in an OEM server infrastructure where the server is on-premises. Consider an example where the OEM server infrastructure enables an accelerator card to perform certain functions such as live video streaming. In that case, the IB security mode in which the root of trust is extended from the server (e.g., the host processor) to the sudo role on the operating system can be used. The sudo role refers to a computer operating system function that enables a user to execute a program with the security privileges of another user.

[0080] When the accelerator card provides live video streaming in a public cloud computing environment, such as a hyperscale computing environment, the OOB security mode can be used. In that case, the root of trust is the BMC located on the server rather than the host processor. Since external users may be presented with access to a live video streaming service on a server host within the public cloud, it may not be secure to use the host processor within the public cloud computing environment as the root of trust.

[0081] According to the configuration of the present invention described herein, the OOB security mode can support various commands that can be issued from the BMC. The satellite controller, for example, can respond to such commands from the BMC when the OOB security mode is implemented within the accelerator card. These commands support secure firmware updates (e.g., updating the configuration memory with a different boot image).

[0082] The following are exemplary commands that can be supported by the satellite controller. · Read the security status information of the accelerator card. When this command is executed by the satellite controller, it is a read command that provides information regarding the write protection status, access mode, and boot image authentication status for each configuration device (e.g., configuration memory 216 and / or recovery configuration memory 218). · Select the default boot device. This command is a write command that provides the option for the programmable IC 132 to select one configuration device as the default boot device from which to boot each time power is applied. For example, the default boot device can be set in the configuration memory 216 or the recovery configuration memory 218 using this command. · Configure the security settings for the selected configuration device. This command is a write command that provides the option to apply any of the available security settings on the accelerator card to the selected configuration device. The security setting options include various modes of SPI access and enabling / disabling writing to the configuration memory 216 and / or the recovery configuration memory 218. · Authenticate the satellite controller firmware and perform a secure firmware update for the satellite controller. This refers to a set of read and write commands that enable authentication of the satellite controller firmware and update of the satellite controller firmware via the OOB communication channel. As an example, the authentication can include selection of default AES or encryption / decryption and CRC checking during firmware update. · Secure firmware update of the main configuration device. This refers to a set of read and write commands that enable secure firmware updates for the configuration memory 216 and / or the recovery configuration memory 218. In response to receiving such commands, the satellite controller checks the security ID from the PROM and verifies that the update of the configuration memory is permitted. Only when the verification of the security ID is successful, the write commands in this category become valid. The commands in this category include status read, transfer of the boot image payload, and CRC check. Inside the satellite controller, these commands trigger corresponding actions for the satellite controller to execute, writing the boot image to the correct sector of the configuration memory, performing a CRC comparison on the boot image, and retrying in case of failure. · Authentication of the main configuration device content. This refers to a set of read and write commands that enable complete authentication of the boot image within the configuration memory 216 and / or the recovery configuration 218. In one or more exemplary implementations, the specific authentication method or protocol used may vary depending on the specific security ID read from the PROM. For example, any one of a plurality of different security IDs may be specified in the PROM 206, and each of the plurality of security IDs specifies an OOB security mode, and each security ID specifies a different predefined authentication method implemented by the satellite controller. The satellite controller can support a plurality of different authentication methods, but implements one authentication method at runtime based on the security ID. The authentication status can be provided by a status command. In case of authentication failure, the satellite controller can completely erase the unauthenticated content. · Transfer of authenticated content from the primary configuration device to the secondary configuration device. This command enables the copying of content from a primary configuration device such as the configuration memory 216 to a recovery device such as the recovery configuration device 218. This command is provisioned in hardware and can be supported by firmware to achieve fault tolerance. In the event of corruption or loss of data in the configuration memory 216, the programmable IC 132 can be configured from the recovery configuration memory 218. To enable this redundancy feature, the satellite controller copies the configuration data or boot image from the configuration memory 216 to the recovery configuration memory 218, thereby eliminating the need to perform relatively slow updates separately for each configuration memory via an OOB communication channel that operates at a slower speed than the IB communication channel. The copying of content is enabled only in response to the successful authentication by the satellite controller of the configuration data stored in the configuration memory 218. In one aspect, the authentication information for each configuration device can be stored in the internal non-volatile memory of the satellite controller for mutual verification during each command operation.

[0083] In one or more exemplary implementations, the above-described commands may be executed in the background. That is, the programmable IC 132 can continue to operate while one or more of the above-described commands are being executed in the background. For example, the programmable IC 132 can boot from authentication content stored in the main configuration device and start executing a workload (e.g., executing a task offloaded by a host computer using a user-specific circuit implemented therein). While the programmable IC 132 is executing the workload, the satellite controller can obtain write access to the main configuration device and perform a secure update of the data stored in the main configuration device as a background operation. After the update is successful, for example, after storing an authenticated boot image for the programmable IC 132, the accelerator card can be rebooted with the new firmware. Upon rebooting, the programmable IC 132 loads the new boot image, thereby enabling an update of the secure circuit design implemented within the programmable IC 132.

[0084] The firmware of the satellite controller enables or disables security functions based on the security ID read from the PROM 206. The security level and implementation details for each security level are predefined and each security ID can be assigned. The above-described commands can be enabled only in accordance with the requirements of the security ID. Each of the commands can have a custom configuration or implementation used based on the security ID written to the PROM 206.

[0085] FIG. 5 shows an exemplary architecture 500 of an IC. In one aspect, the architecture 500 can be implemented within a programmable IC. For example, the architecture 500 can be used to implement a field programmable gate array (FPGA). The architecture 500 can also represent a system on chip (SoC) type of IC. An SoC is an IC that includes a processor for executing program code and one or more other circuits. The other circuits can be implemented as hardwired circuits, programmable circuits, and / or combinations thereof. The circuits can operate in cooperation with each other and / or with the processor.

[0086] As shown, the architecture 500 includes several different types of programmable circuits, such as logic blocks. For example, the architecture 500 can include a multi-gigabit transceiver (MGT) 501, configurable logic blocks (CLB) 502, random access memory blocks (BRAM) 503, input / output blocks (IOB) 504, configuration and clocking logic (CONFIG / CLOCKS) 505, digital signal processing blocks (DSP) 506, special I / O blocks 507 (e.g., configuration ports and clock ports), and other programmable logic 508 such as digital clock managers, analog-to-digital converters, and system monitoring logic. The architecture 500 can include a number of different programmable tiles.

[0087] In some ICs, each programmable tile includes a programmable interconnect (INT) 511 having a standardized connection to corresponding interconnect elements (INT) 511 in each adjacent tile. Thus, the INTs 511 together implement the programmable interconnect structure of the illustrated IC. Each INT 511 also includes connections to programmable logic elements within the same tile, as shown by the example included on the right side of FIG. 5.

[0088] For example, CLB502 may include a configurable logic element (CLE) 512 that can be programmed to implement a single INT511 in addition to user logic. BRAM503 may include a BRAM logic element (BRL) 513 in addition to one or more INT511s. Typically, the number of INT511s included within a tile depends on the height of the tile. As depicted, the BRAM tile has the same height as five CLBs, although other numbers (e.g., four) may be used. DSP tile 506 may include a DSP logic element (DSPL) 514 in addition to an appropriate number of INT511s. IOB504 may include, for example, two instances of an I / O logic element (IOL) 515 in addition to one instance of INT511. The actual I / O pads connected to IOL515 may not be limited to the area of IOL515.

[0089] In the example depicted in FIG. 5, for example, a horizontal area near the center of the die formed in regions 505, 507, and 508 may be used for configuration, clock, and other control logic. A vertical area 509 extending from this horizontal area may be used to distribute clock and configuration signals across the width of the programmable IC.

[0090] Some ICs utilizing the architecture shown in FIG. 5 include additional logic blocks that disrupt the regular columnar structure that makes up most of the IC. The additional logic blocks can be programmable blocks and / or dedicated circuitry. For example, a processor block shown as PROC510 spans several columns of CLBs and BRAMs.

[0091] In one aspect, PROC510 can be implemented as a dedicated circuit assembled as part of a die implementing the programmable circuitry of the IC, for example, as a hardwired processor. PROC510 can represent any of a variety of different processor types and / or systems, ranging in complexity from an individual processor, e.g., a single core that can execute program code, to an entire processor system having one or more cores, modules, coprocessors, or interfaces.

[0092] In another aspect, PROC510 can be omitted from architecture 500 and replaced with one or more of the other types of programmable blocks described. Further, such blocks can be utilized to form a "soft processor" in that they can be used to form a processor that can execute program code as in the case of PROC510, using various blocks of the programmable circuitry.

[0093] The phrase "programmable circuitry" refers to programmable circuit elements within the IC, e.g., the various programmable or configurable circuit blocks or tiles described herein, and the interconnect circuitry that selectively couples the various circuit blocks, tiles, and / or elements according to configuration data loaded into the IC. For example, the circuit blocks shown in FIG. 5 that are external to PROC510, such as CLB502 and BRAM503, are considered part of the programmable circuitry of the IC.

[0094] Generally, the functionality of a programmable circuit is not established until configuration data is loaded into the IC. A set of configuration bits can be used to program the programmable circuit of an IC, such as an FPGA. The configuration bits are typically referred to as a "configuration bitstream". Generally, a programmable circuit will not operate or function until the configuration bitstream is first loaded into the IC. The configuration bitstream effectively implements a specific circuit design within the programmable circuit. The circuit design specifies, for example, the functional aspects of the programmable circuit blocks and the physical connectivity between the various programmable circuit blocks.

[0095] "Hardwired" or "hardened", i.e., non-programmable circuits, are manufactured as part of the IC. Unlike programmable circuits, hardwired circuits or circuit blocks are not implemented after the manufacture of the IC by loading a configuration bitstream. Hardwired circuits are generally considered to have dedicated circuit blocks and interconnections that function, for example, without first loading a configuration bitstream into the IC, such as PROC510.

[0096] In some cases, a hardwired circuit may have one or more operating modes that can be set or selected according to register settings or values stored in one or more memory elements within the IC. The operating mode can be set, for example, by loading a configuration bitstream into the IC. Despite this capability, a hardwired circuit is not considered a programmable circuit because it is operable and has a specific function when manufactured as part of the IC.

[0097] In the case of an SoC, the configuration bitstream can identify the circuitry to be implemented within the programmable circuitry and the program code to be executed by the PROC510 or the soft-processor. In some cases, the architecture 500 includes a dedicated configuration processor that loads the configuration bitstream into the appropriate configuration memory and / or processor memory. The dedicated configuration processor does not execute the program code of a particular user. In other cases, the architecture 500 can use the PROC510 to receive the configuration bitstream, load the configuration bitstream into the appropriate configuration memory, and / or extract the program code for execution.

[0098] FIG. 5 is intended to show an exemplary architecture that can be used to implement a programmable circuitry, e.g., an IC including a programmable fabric. For example, the number of logic blocks within a column, the relative width of a column, the number and order of columns, the type of logic blocks included in a column, the relative size of the logic blocks, and the interconnect / logic implementation aspect included on the right side of FIG. 5 are purely exemplary. In an actual IC, for example, to facilitate an efficient implementation of a user circuit design, typically two or more adjacent columns of CLBs are always included where the CLBs appear. However, the number of adjacent CLB columns can vary depending on the overall size of the IC. Further, the size and / or positioning of blocks such as the PROC510 within the IC are for illustrative purposes only and are not intended to be limiting.

[0099] FIG. 5 is provided as an exemplary implementation of the programmable IC 132 and is not intended to limit the types of ICs that can be implemented on the accelerator card for the purposes of the configuration of the invention described herein. Other types of programmable ICs may be used. In some cases, the programmable IC 132 may include a hardened bus endpoint, such as a PCIe endpoint, for communicating with a host computer. In other cases, the bus endpoint may be implemented in programmable circuitry. In this regard, the secure circuit design may be implemented in fully programmable logic, or partially programmable logic, in response to loading of the boot image, and in part by one or more hardwired circuit blocks in response to loading of the boot image. In some cases, the programmable IC may include an array of processors that can operate in cooperation with other processors and / or subsystems (e.g., programmable logic) of the programmable IC.

[0100] For purposes of explanation, specific nomenclature is set forth to provide a complete understanding of the various inventive concepts disclosed herein. However, the terminology used herein is for the purpose of describing only particular aspects of the configuration of the invention and is not intended to be limiting.

[0101] As defined herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0102] As defined herein, the terms "at least one", "one or more", and "and / or" are open-ended expressions that are both conjunctive and disjunctive in operation, unless otherwise specified. For example, each of the expressions "at least one of A, B, and C", "at least one of A, B, or C", "one or more of A, B, and C", "one or more of A, B, or C", and "A, B, and / or C" means only A, only B, only C, A and B together, A and C together, B and C together, or A, B, and C together.

[0103] As defined herein, the term "automatically" means without human intervention. In some contexts, the term "user" means a human being.

[0104] As defined herein, the term "computer-readable storage medium" means a storage medium that includes or stores program code for use by or in connection with an instruction execution system, apparatus, or device. As defined herein, a "computer-readable storage medium" is not a transitory propagation signal per se. A computer-readable storage medium can be, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of these. The various forms of memory described herein are examples of computer-readable storage media. A non-exhaustive list of more specific examples of computer-readable storage media can include, for example, a portable computer diskette, a hard disk, a RAM, a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an electronically erasable programmable read-only memory (EEPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, or a floppy disk, among others.

[0105] As defined herein, the terms "when", "upon", or "in response thereto" mean "in response to" or "responsive to" depending on the context. As defined herein, the terms "responsive to" and "in response to" mean to immediately respond or react to an action or event. The response or reaction is performed automatically. Thus, when a second action is performed "responsive to" a first action, there is a causal relationship between the occurrence of the first action and the occurrence of the second action. The term "responsive to" indicates a causal relationship.

[0106] As defined herein, the term "processor" means at least one circuit capable of executing instructions included in program code. The circuit may be an integrated circuit or may be embedded within an integrated circuit. The processor may be hardwired or implemented using programmable logic.

[0107] As defined herein, the term "substantially" means that the recited characteristics, parameters, or values need not be achieved exactly, but that deviations or variations, including for example, tolerances, measurement errors, measurement accuracy limitations, and other factors known to those of skill in the art, may occur in amounts that do not exclude the effect the characteristic is intended to provide.

[0108] The terms first, second, etc. may be used herein to describe various elements. These terms are used only to distinguish one element from another and thus, unless otherwise specified or the context clearly indicates otherwise, these elements should not be limited by these terms.

[0109] A computer program product may include a computer-readable storage medium having computer-readable program instructions for causing a processor to execute aspects of the configuration of the present invention described herein. Within the present disclosure, the term "program code" is used interchangeably with the term "computer-readable program instructions." The computer-readable program instructions described herein may be downloaded from the computer-readable storage medium to respective computing / processing devices via a network, such as, for example, the Internet, a LAN, a WAN, and / or a wireless network, or to an external computer or external storage device. The network may include edge devices including copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each respective computing / processing device.

[0110] Computer-readable program instructions for performing the operations for the configuration of the present invention described herein can be either source code or object code described by any combination of one or more programming languages including assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, or object-oriented programming languages and / or procedural programming languages. The computer-readable program instructions can include state-setting data. The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network including a LAN or WAN, or a connection to an external computer (e.g., via the Internet using an Internet service provider) can be made.

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

[0112] These computer-readable program instructions are provided to the processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to create means for implementing the functions / acts specified in the blocks of the flowchart and / or block diagram through the instructions executed via the processor of the computer or other programmable data processing apparatus, and thus a machine is produced. These computer-readable program instructions may also be stored in a computer-readable storage medium having stored instructions therein to provide a product comprising instructions for implementing the manner of operation specified in the blocks of the flowchart and / or block diagram, and to direct a computer, programmable data processing apparatus, and / or other devices to function in a particular manner.

[0113] The computer-readable program instructions may also be loaded onto a computer, other programmable apparatus, or other device to cause a series of operations to be performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / acts specified in the blocks of the flowchart and / or block diagram.

[0114] The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various aspects of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of code that comprises one or more executable instructions for implementing the specified action.

[0115] In some alternative implementations, the operations described in the blocks may occur in different orders than those described in the figures. For example, two blocks shown in succession may be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order depending on the associated functionality. In other examples, the blocks may generally be executed in ascending order, but in still other examples, one or more blocks may be executed in various orders such that the results are stored and used by subsequent blocks or other blocks that do not immediately follow. Also note that each block of the block diagrams and / or flowchart diagrams, as well as combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a dedicated hardware-based system that performs the specified functions or actions, or by a combination of dedicated hardware and computer instructions.

[0116] The corresponding structures, materials, acts, and equivalents of all means-plus-function or step-plus-function elements that may be found in the following claims are intended to include any structure, material, or act for performing the functions in combination with other claimed elements as specifically claimed.

[0117] The accelerator card may include a read-only memory configured to store a security ID in a specified field within the read-only memory, and a satellite controller configured to read the security ID in response to a reset event. The satellite controller may be configured to select a security mode from a plurality of security modes based on the security identifier and implement the selected security mode within the accelerator card.

[0118] The foregoing and other implementations may each optionally include, individually or in combination, one or more of the following features. Some exemplary implementations include all of the following features in combination.

[0119] In one aspect, the plurality of security modes includes an IB security mode and an OOB security mode.

[0120] In the IB security mode, the host processor of the host computer communicating with the accelerator card can be designated as the root of trust of the accelerator card. In the OOB security mode, the BMC of the host computer can be designated as the root of trust of the accelerator card.

[0121] In another aspect, the accelerator card includes a programmable IC and a configuration memory for the programmable IC.

[0122] In the IB security mode, for receiving the boot image, the IB communication channel between the host processor and the programmable IC can be activated. The programmable IC is configured to authenticate the boot image and store the boot image in the configuration memory.

[0123] In the OOB security mode, for receiving the boot image, the OOB communication channel between the satellite controller and the BMC can be activated. The satellite controller is configured to authenticate the boot image and store the boot image in the configuration memory.

[0124] In another aspect, the accelerator card includes a configuration memory, a programmable IC, a satellite controller, and a switch coupled to the satellite controller. The switch is configured by the satellite controller to provide write access to the configuration memory to the programmable IC or the satellite controller based on the selected security mode.

[0125] For example, in the IB security mode, the switch is configured to provide read and write access to the configuration memory of the programmable IC and to disconnect the satellite controller from the configuration memory. In the OOB security mode, the switch is configured to provide read-only access to the configuration memory of the programmable IC and to provide the satellite controller with read and write access to the configuration memory.

[0126] The accelerator card may include a control circuit configured to provide a select signal to the switch in response to a control signal from the satellite controller.

[0127] In another aspect, the read-only memory has a security identifier pre-loaded and is readable only by the satellite controller.

[0128] The description of the configurations of the invention provided herein is for purposes of illustration only and is not intended to be exhaustive or limited to the disclosed forms and examples. The terms used herein are selected to explain the principles of the configurations of the invention, actual applications, or technological improvements to technologies found in the market and / or to enable those skilled in the art to understand the configurations of the invention disclosed herein. Modifications and variations may be apparent to those skilled in the art without departing from the scope and spirit of the configurations of the invention described. Therefore, reference should be made to the following claims rather than the foregoing disclosure as indicating the scope of such features and implementations.

Claims

1. An accelerator card, comprising: A read-only memory configured to store a security identifier in a specified field within the read-only memory; A satellite controller configured to read the security identifier in response to a reset event; The satellite controller is configured to select a security mode from a plurality of security modes based on the security identifier and implement the selected security mode within the accelerator card. An accelerator card, wherein the satellite controller is configured to select a security mode from a plurality of security modes based on the security identifier and implement the selected security mode within the accelerator card.

2. The plurality of security modes include: An in-band security mode that designates a host processor of a host computer communicating with the accelerator card as a root of trust for the accelerator card; An out-of-band security mode that designates a baseboard management controller of the host computer as the root of trust for the accelerator card. The accelerator card according to claim 1.

3. A programmable integrated circuit; A configuration memory for the programmable integrated circuit; The in-band security mode enables an in-band communication channel between the host processor and the programmable integrated circuit for receiving a boot image, and the programmable integrated circuit is configured to authenticate the boot image and store the boot image in the configuration memory. The accelerator card according to claim 2.

4. A programmable integrated circuit; A configuration memory for the programmable integrated circuit; The out-of-band security mode enables an out-of-band communication channel between the satellite controller and the baseboard management controller for receiving a boot image, and the satellite controller is configured to authenticate the boot image and store the boot image in the configuration memory. The accelerator card according to claim 2.

5. A programmable integrated circuit; A configuration memory for the programmable integrated circuit; ​ ​ ​ ​ A switch coupled to the configuration memory, the programmable integrated circuit, and the satellite controller, the switch being configured by the satellite controller to provide write access to the configuration memory to the programmable integrated circuit or the satellite controller based on the selected security mode. The accelerator card according to claim 2, further comprising.

6. In the in-band security mode, the switch is configured to provide read and write access to the configuration memory to the programmable integrated circuit and to disconnect the satellite controller from the configuration memory. The accelerator card according to claim 5.

7. In the out-of-band security mode, the switch is configured to provide read-only access to the configuration memory to the programmable integrated circuit and to provide read and write access to the configuration memory to the satellite controller. The accelerator card according to claim 5.

8. A control circuit configured to provide a selection signal to the switch in response to a control signal from the satellite controller. The accelerator card according to claim 5, further comprising.

9. The accelerator card according to claim 1, wherein the read-only memory has the security identifier pre-loaded and is readable only by the satellite controller.

10. A method of configuring a security mode for an accelerator card, the method comprising: Using a satellite controller of the accelerator card to read a security identifier from a designated field of a read-only memory of the accelerator card in response to a reset event; Selecting a security mode from a plurality of security modes for the accelerator card based on the security identifier and using the satellite controller; Implementing the selected security mode within the accelerator card; A method including.

11. The accelerator card includes a programmable integrated circuit and a configuration memory for the programmable integrated circuit, and the method includes. In response to implementing an in-band security mode, designating a host processor of a host computer communicating with the accelerator card as a root of trust for the accelerator card; In response to implementing the in-band security mode, enabling an in-band communication channel between the host processor and the programmable integrated circuit for receiving a boot image; further comprising; the programmable integrated circuit being configured to authenticate the boot image and store the boot image in the configuration memory; The method according to claim 10. **Claim 12** The accelerator card includes a programmable integrated circuit and a configuration memory for the programmable integrated circuit, and the method includes: In response to implementing an out-of-band security mode, designating a baseboard management controller of a host computer as a root of trust for the accelerator card; In response to implementing the out-of-band security mode, enabling an out-of-band communication channel between the satellite controller and the baseboard management controller for receiving a boot image; further comprising; the satellite controller being configured to authenticate the boot image and store the boot image in the configuration memory; The method according to claim 10. **Claim 13** The accelerator card includes a programmable integrated circuit; a configuration memory for the programmable integrated circuit; a switch coupled to the configuration memory, the programmable integrated circuit, and the satellite controller, the switch being configured by the satellite controller to provide write access to the configuration memory to the programmable integrated circuit or the satellite controller based on the selected security mode; The method according to claim 10, comprising. **Claim 14** In response to implementing an in-band security mode, configuring the switch to provide read and write access to the configuration memory to the programmable integrated circuit and disconnect the satellite controller from the configuration memory; The method according to claim 13, further comprising. **Claim 15** In response to implementing the out-of-band security mode, configuring the switch to provide read-only access to the configuration memory for the programmable integrated circuit and to provide read and write access to the configuration memory for the satellite controller The method of claim 13, further comprising

Images