Patent Application
20230078058
The technology of the disclosure relates to computing systems employing one or more central processing units (CPUs), and more particularly boot-up operations in the CPUs.
Computing systems include one or more central processing units (CPUs). The CPUs are provided as integrated circuit (IC) chips (also called “CPU chips”) that are mounted on a circuit board. The computing system can also include other computing resources mounted on the same or a coupled circuit board, such as boot storage, memory, and interfacing circuits. For example, if the computing system is employed as a computer server, the computing system can be provided on a circuit board as server blade.
The computing system undergoes a start-up process known as a “boot” or “boot-up” process when a power cycle occurs or a reset is performed. During a boot process, various hardware components and software processes in the computing system are initialized and other boot-up operations performed to prepare these components and processes to be able to perform tasks according to operating system and application software executed by a CPU. A computing system may include a separate boot processor that loads in and executes a boot program code to perform lower-level boot-up operations to prepare the hardware and software components in the computing system to be utilized. It is usually desired for the boot program code to be able to change and be upgraded or updated over time, so the boot program code is typically loaded from a boot memory, such as a programmable read-only memory (ROM), that is separate and apart from the boot processor. When the boot processor undergoes a reset, the boot processor has a lower-level bootloader program code that can be executed to load in a boot program code from the boot memory. In this manner, the boot program code can be updated over time. The boot processor executes the boot program code to perform boot-up operations, including but not limited to initialization of clock circuits, power controls system, interfaces, memory systems, and loading in basic input/output system (BIOS) firmware to be executed by the CPU to perform CPU-specific boot-up operations.
It is important that the computing system is designed to include a secure boot-up system to avoid unauthorized software and physical attacks into the resources of the CPU. One example of such an attack is to obtain access to internal memory of the computing system, which may provide information on the operation of the CPU. It is also important to prevent physical attacks during a boot-up operation process of a computing system. Thus, as part of a secure boot-up design for a computing system, it is important that the computing system have the capability to determine if the boot-up operation processes are behaving in an expected manner and to detect any behaviors that are unexpected. For example, loading in an unauthorized modified version of boot program code from boot memory would be an unexpected behavior. If a third party can modify the boot program code such that the boot process of the computing system executes the modified boot program code without detecting the modification, the third party can alter and control the boot-up operations of the computing system. These altered boot-up operations can include other tampering into the operations of the computing system that can make the CPU vulnerable to other attacks.
The Trusted Platform Modules (TPM) standard ISO/IEC 11889 has been developed to secure hardware in computing systems through integrated cryptographic keys. The TPM standard calls for providing a separate processor in a computing system for creating a hash key summary of a hardware and software configuration of a computing system as part of a boot-up operation to verify that the software has not been changed. The job of the TPM processor is to ensure that the boot process starts from a trusted combination of hardware and software and continues until the operating system of the CPU has been loaded and fully booted and applications are running. However, the TPM processor has to be booted-up and be operational itself to be able to perform verifications of the hardware and software configuration of a computing system.
Aspects disclosed herein include computing systems employing a secure boot processing system that disallows in-bound access when performing immutable boot-up tasks for enhanced security. Related methods and computer-readable media are also disclosed. The computing system includes one or more central processing unit (CPUs) that each include one or more CPU cores. The computing system includes a secure boot processing system that includes one or more processors that perform boot-up operations in response to the computer system being powered on or reset (referred to as “power-on reset” (POR)). The secure boot processing system includes a secure boot processor that includes an immutable secure boot subsystem that includes an immutable secure boot controller. The immutable secure boot controller performs lower-level, immutable boot-up tasks. The immutable secure boot controller can also generate requests over a boot system interface of the secure boot processing system to initiate boot-up operations for other components and peripherals external to the secure boot processing system. These immutable boot-up tasks performed by the immutable secure boot controller can involve access and control of resources of the computing system that are critical to the security of the computing system, and thus are critical to secure the computing system from being corrupted from unauthorized devices or agents outside of the secure boot subsystem.
In this regard, in exemplary aspects disclosed herein, to prevent or mitigate the ability of an unauthorized device or agent access to the immutable secure boot subsystem that could compromise the security of the computing system, the immutable secure boot controller is configured to disallow external, inbound access to boot system interface of the secure boot processing system to perform immutable boot-up tasks. In this manner, there is not an access path for an external unauthorized device or agent to change early immutable boot-up tasks performed by the immutable secure boot controller, or otherwise access the secure boot processing system that could corrupt the computing system. After the immutable boot-up tasks are performed, the immutable secure boot controller can allow external, inbound access to the boot system interface of the secure boot processing system. In this regard, the immutable secure boot controller allows inbound access to the boot system interface to cause a bootloader program to be loaded into a bootloader memory that is accessible to the secure boot processor in the secure boot processing system. The secure boot processor can execute instructions in the loaded-in bootloader program to perform mutable boot-up tasks that are a part of boot-up operations. Thus, the secure boot processing system is designed on the principal of least privileges wherein the secure boot processing system only allows access to resources that are desired or necessary to perform assigned functions.
In one example, the secure boot processing system includes a plurality of boot system interfaces. For example, one boot system interface of the secure boot processing system may be coupled to an input/output (I/O) bus that is coupled to the bootloader memory that is configured to store the loaded-in bootloader program. In one example, inbound access from the I/O bus to the secure boot processing system may be disallowed by the secure boot processing system not having an inbound port coupled to the I/O bus. In this manner, only outbound requests are physically allowed by the secure boot processing system to the I/O bus. Another boot system interface of the secure boot processing system may be coupled to a dedicated bootloader bus that is coupled to an external memory that stores the bootloader program and is accessed under control of the immutable secure boot controller to load in the bootloader program from the external memory to the bootloader memory. Other methods of not allowing access to the secure boot processing system in response to performing immutable boot-up tasks can also be provided.
Note that the secure boot processing system may include hardware resources to perform trusted management module (TMM) tasks to verify the hardware and software configuration of the computing system setup as part of the boot-up operation. For example, the secure boot processing system can support use of cryptographic keys to verify the image bootloader program loaded in from external memory to be executed by the secure boot processor as part of performing mutable boot-up tasks. The bootloader program can be verified by TMM tasks. However, the immutable secure boot controller may perform the lower-level, immutable boot-up tasks of the boot-up operation before TMM resources are available as a security resource. Thus, by the secure boot processing subsystem and its immutable secure boot controller being configured to not allow inbound access to secure boot processing system in response to performing immutable boot-up tasks, external devices or agents cannot access resources in or available to the secure boot processing system that may otherwise be available before TMM resources are available.
In other exemplary aspects, the immutable secure boot controller includes a bootstrap controller that is configured to perform a hardware state machine out of POR. The bootstrap controller can be provided to execute a hardware state machine (e.g., register transfer level (RTL) circuits) to perform the initial immutable boot-up tasks not based solely on execution of firmware. In this regard, in response to a POR of the computing system, the bootstrap controller is configured to execute the hardware state machine to initially disallow inbound access to secure boot processing system through the secure boot system interface for security reasons. The bootstrap controller can perform immutable boot-up tasks, such as initialization clock circuits for example. In one example, the bootstrap controller can also access one or more boot mode registers (e.g., electronic fuses (efuses)) to determine security policies and related authentication indicators (e.g., keys) to determine the boot mode of the computing system to determine the appropriate immutable boot-up tasks to be performed based on the boot mode. The bootstrap controller is configured to perform boot-up tasks to make certain hardware resources in the secure boot processing system available or not available depending on the boot mode for enhanced security, and because in this example, at this point in the boot-up operations, the TMM processor is not available to perform security. In one example, the subsequent immutable boot-up tasks based on the boot mode are performed by the secure boot processor in the immutable secure boot subsystem executing instructions from an immutable boot read-only memory (ROM) program stored in on-chip ROM. Different immutable boot-up tasks can be performed based executing the boot ROM program based on the boot mode. For example, if the boot mode registers indicate a debug boot mode, the secure boot processor can allow a debug mode interface (e.g., JTAG interface) to be available to allow an external device direct access to the CPUs of the computing system. In another example, if the boot mode registers indicate a return merchandise authorization (RMA) mode, the secure boot processor can make an interface available and accessible for test vectors to be injected into the computing system. Other exemplary boot modes that can be configured in the secure boot processing system includes a security key revocation mode that allows security keys to be revoked security keys, a disable debug mode when normal boot-up operations are desired, and an anti-rollback security mode for preventing a rollback of the security keys.
After appropriate authentications are performed, the immutable secure boot controller can then, for example, execute instructions in the boot ROM program to reallow inbound access to the secure boot processing system through the boot system interface. The immutable secure boot controller can then cause the bootloader program to be loaded from external memory (e.g., an electronically erasable programmable ROM (EEPROM)) into a bootloader memory. Instructions in the bootloader program can then be executed by the secure boot processor to perform mutable boot-up tasks as part of the boot-up operation, including but not limited to performing TMM functions. The mutable boot-up tasks can include initializing other hardware resources in the computing system, including the CPUs, and load-in further software, such as an operating system (OS) for example, to prepare the CPUs for application execution in a normal processing mode after boot-up operations are completed.
In this regard, in one exemplary aspect, a computing system is provided. The computing system comprises a secure boot processing system that comprises a boot system interface and a secure boot processor comprising an immutable secure boot controller. The secure boot processor is coupled to the boot system interface. The secure boot processor subsystem is configured to receive a power-on reset (POR) signal in response to a POR signal indicating a boot-up state. In response to the POR signal indicating the boot-up state, the immutable secure boot controller is configured to disallow inbound access to the secure boot processing system from the boot system interface, perform one or more immutable boot-up tasks, reallow inbound access to the secure boot processing system from the boot system interface, and load in a bootloader program over the boot system interface to a bootloader memory. The secure boot processor is configured to execute the bootloader program in the bootloader memory to perform one or more mutable boot-up tasks.
In another exemplary aspect, a method of performing a secure boot process in a computing system is provided. The method comprises receiving a POR signal in a secure boot processing system. In response to receiving the POR signal indicating the boot-up state, the method also comprises disallowing inbound access to the secure boot processing system from a boot system interface, performing one or more immutable boot-up tasks in the secure boot processing system, reallowing inbound access to the secure boot processing system from the boot system interface, loading in a bootloader program over the boot system interface to a bootloader memory, and executing the bootloader program in the bootloader memory to perform one or more mutable boot-up tasks in the secure boot processing system.
In another exemplary aspect, a non-transitory computer-readable medium is provided. The non-transitory computer-readable medium has stored thereon computer executable instructions which, when executed by a processor, cause the processor to receive a POR signal in a secure boot processing system in response to a POR signal indicating a boot-up state. In response to the POR signal indicating the boot-up state, the computer executable instructions which, when executed by a processor, cause the processor to disallow inbound access to the secure boot processing system from a boot system interface, perform one or more immutable boot-up tasks in the secure boot processing system, reallow inbound access to the secure boot processing system from the boot system interface, load in a bootloader program over the boot system interface to a bootloader memory, and execute the bootloader program in the bootloader memory to perform one or more mutable boot-up tasks in the secure boot processing system.
Those skilled in the art will appreciate the scope of the present disclosure and realize additional aspects thereof after reading the following detailed description of the preferred embodiments in association with the accompanying drawing figures.
The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.
Aspects disclosed herein include computing systems employing a secure boot processing system that disallows in-bound access when performing immutable boot-up tasks for enhanced security. Related methods and computer-readable media are also disclosed. The computing system includes one or more central processing unit (CPUs) that each include one or more CPU cores. The computing system includes a secure boot processing system that includes one or more processors that perform boot-up operations in response to the computer system being powered on or reset (referred to as “power-on reset” (POR)). The secure boot processing system includes a secure boot processor that includes an immutable secure boot subsystem that includes an immutable secure boot controller. The immutable secure boot controller performs lower-level, immutable boot-up tasks. The immutable secure boot controller can also generate requests over a boot system interface of the secure boot processing system to initiate boot-up operations for other components and peripherals external to the secure boot processing system. These immutable boot-up tasks performed by the immutable secure boot controller can involve access and control of resources of the computing system that are critical to the security of the computing system, and thus are critical to secure the computing system from being corrupted from unauthorized devices or agents outside of the secure boot subsystem.
In this regard, in exemplary aspects disclosed herein, to prevent or mitigate the ability of an unauthorized device or agent access to the immutable secure boot subsystem that could compromise the security of the computing system, the immutable secure boot controller is configured to disallow external, inbound access to boot system interface of the secure boot processing system to perform immutable boot-up tasks. In this manner, there is not an access path for an external unauthorized device or agent to change early immutable boot-up tasks performed by the immutable secure boot controller, or otherwise access the secure boot processing system that could corrupt the computing system. After the immutable boot-up tasks are performed, the immutable secure boot controller can allow external, inbound access to the boot system interface of the secure boot processing system. In this regard, the immutable secure boot controller allows inbound access to the boot system interface to cause a bootloader program to be loaded into a bootloader memory that is accessible to the secure boot processor in the secure boot processing system. The secure boot processor can execute instructions in the loaded-in bootloader program to perform mutable boot-up tasks that are a part of boot-up operations. Thus, the secure boot processing system is designed on the principal of least privileges wherein the secure boot processing system only allows access to resources that are desired or necessary to perform assigned functions.
In one example, the secure boot processing system includes a plurality of boot system interfaces. For example, one boot system interface of the secure boot processing system may be coupled to an input/output (I/O) bus that is coupled to the bootloader memory that is configured to store the loaded-in bootloader program. In one example, inbound access from the I/O bus to the secure boot processing system may be disallowed by the secure boot processing system not having an inbound port coupled to the I/O bus. In this manner, only outbound requests are physically allowed by the secure boot processing system to the I/O bus. Another boot system interface of the secure boot processing system may be coupled to a dedicated bootloader bus that is coupled to an external memory that stores the bootloader program and is accessed under control of the immutable secure boot controller to load in the bootloader program from the external memory to the bootloader memory. Other methods of not allowing access to the secure boot processing system in response to performing immutable boot-up tasks can also be provided.
In this regard,
With continuing reference to
An example of an immutable boot-up task is to initiate clock circuits 120 that generate clock signals for synchronous circuits in the computing system 100. Another example of an immutable boot-up task is determining a boot-up mode of the computing system 100 to control boot-up operations and selectively determine which external interfaces in the secure boot processing system 110 to enable. For example, in a debug boot mode, it may be desired to enable a debug access port 122 to allow debug commands 124 to be issued to the computing system 100 for debug purposes. For example, the debug commands 124 can be provided over a configuration and debug bus 126 to access a debug access port 122 of the CPUs 102(1)-102(N), the clock circuits 120, and thermal/power sensor 128. However, in a normal boot mode, an immutable boot-up task may be to not enable or disable the debug access port 122 as a security measure.
With continuing reference to
By dividing the boot-up operations performed by the secure boot processing system 110 into the immutable boot-up tasks performed by the immutable secure boot controller 118 and mutable boot-up tasks performed by the secure boot processor 114, the secure boot processing system 110 provides an enhanced security for performing boot-up operations for the computing system 100. As discussed in more detail below, the immutable secure boot controller 118 can be configured to perform immutable boot-up tasks and to disallow in-bound access to the immutable secure boot controller 118 when performing the immutable boot-up tasks. Because the immutable secure boot controller 118 is not using the bootloader program 130 in the bootloader memory 132 that is accessed through the system I/O bus 108, the immutable secure boot controller 118 can limit or not allow inbound communications to be received through the boot system interface 134 from the system I/O bus 108 when performing immutable boot-up operations, as a measure of security. These immutable boot-up tasks performed by the immutable secure boot controller 118 can involve access and control of resources of the computing system 100 that are critical to the security of the computing system 100, and thus are critical to secure the computing system 100 from being corrupted from external unauthorized devices or agents.
In this example, after the immutable boot-up tasks are performed, the immutable secure boot controller 118 can allow external, inbound access to the boot system interface 134. The immutable secure boot controller 118 causes the bootloader program 130 to initially be loaded through a bootloader bus 136 coupled to an external memory (not shown) (e.g., an electronically-erasable programmable read-only memory (EEPROM)) and forwarded over the system I/O bus 108 to the bootloader memory 132 to be stored and later available for the secure boot processor 114 to execute to perform mutable boot-up tasks. The secure boot processor 114 can perform mutable boot-up tasks as part of continued boot-up operations. In this regard, the secure boot processing system 110 in
In this regard, as shown in
With reference back to
In this example, when the immutable secure boot controller 118 desires to disallow inbound access to the secure boot processing system 110 from the boot system interface 134, the immutable secure boot controller 118 disallows inbound access by the bootloader bus 136 through the bootloader input port(s) 300I. For example, the immutable secure boot controller 118 may disable or deactivate the bootloader input port(s) 300I. In this manner, the bootloader bus 136 cannot be used by an external device to try to gain access to the secure boot processing system 110 when not desired by the immutable secure boot controller 118, such as during the performance of immutable boot-up tasks. Also in this example, when the immutable secure boot controller 118 desires to disallow inbound access to the secure boot processing system 110 from the boot system interface 134, the immutable secure boot controller 118 disallows inbound access through the system I/O bus 108. However, in this example, this is accomplished by an input port not being physically provided between the immutable secure boot subsystem 116 and the system I/O bus 108. In this manner, as examples the immutable secure boot controller 118 can disallow inbound communications over the system I/O bus 108 to access systems in the secure boot processing system 110, such as a cryptographic circuit 312 used for cryptographic authentication and boot mode registers 314 used to determine the boot mode of the computing system 100 (discussed in more detail below). The system output port 304O can be used by the immutable secure boot controller 118 to stream the bootloader program 130 received from the bootloader bus 136 over the system I/O bus 108 to be stored in the bootloader memory 132. The secure boot processor 114 can access the bootloader program 130 in bootloader memory 132 through the system I/O bus 108 through system input port(s) 306I that are controlled to not allow access to the immutable secure boot subsystem 116 and the immutable secure boot controller 118.
With continuing reference to
For example, the secure boot processing system 110, and its immutable secure boot subsystem 116 in particular, may include one or more boot mode registers 314 that are configured to store a boot mode of the computing system 100. The boot mode controls the boot operations and flow performed by the immutable secure boot controller 118. For example, different security measures and allowance/disallowance of access of inbound communications to the immutable secure boot subsystem 116 and secure boot processing system 110 are dependent on the particular boot mode of the computing system 100. In this regard, when the immutable secure boot controller 118 is initiated to perform immutable boot-up tasks in response to the POR signal 112, the immutable secure boot controller 118 accesses the boot mode register(s) 314. As an example, the boot mode register(s) 314 can be provided in the form of electronic fuse (efuse) circuits that can be read and then purposefully blown as part of boot-up operations to not allow changes. The immutable secure boot controller 118 determines the boot mode of the computing system 100 based on the accessed boot mode register(s) 314. The immutable secure boot controller 118 then performs the immutable boot-up tasks based on the determined boot mode for the computing system 100.
In this regard,
With continuing reference to
With continuing reference to
After the boot mode is determined and the immutable boot-up tasks performed by the immutable secure boot controller 118 are completed based on the determined and authenticated boot mode, the immutable secure boot controller 118 can allow inbound access to the bootloader input port(s) 300I for the bootloader program 130 to be loaded from the bootloader bus 136 into the bootloader memory 132 to be executed by the secure boot processor 114. The secure boot processor 114 can then continue with performing mutable boot-up tasks, including loading in the bootloader program 130 over the bootloader interface 136 to the bootloader memory 132 (block 418 in
Other initiator and target devices can be connected to the system bus 510. As illustrated in
The CPU(s) 508 may also be configured to access the display controller(s) 526 over the system bus 510 to control information sent to one or more displays 532. The display controller(s) 526 sends information to display(s) 532 to be displayed via one or more video processors 534, which process the information to be displayed into a format suitable for the display(s) 526. The display(s) 526 can include any type of display, including, but not limited to, a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, a light emitting diode (LED) display, etc.
The processor-based system 500 in
While the non-transitory computer-readable medium 538 is shown in an exemplary embodiment to be a single medium, the term “computer-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable medium” shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the processing device and that cause the processing device to perform any one or more of the methodologies of the embodiments disclosed herein. The term “computer-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical medium, and magnetic medium.
Those of skill in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithms described in connection with the aspects disclosed herein may be implemented as electronic hardware, instructions stored in memory or in another computer readable medium and executed by a processor or other processing device, or combinations of both. The initiator devices and target devices described herein may be employed in any circuit, hardware component, integrated circuit (IC), or IC chip, as examples. A processor is a circuit that can include a microcontroller, a microprocessor, or other circuit that can execute software or firmware instructions. A controller is a circuit that can include microcontroller, a microprocessor, and/or dedicated hardware circuits (e.g., a field programmable gate array (FPGA)) that do not necessarily execute software or firmware instruction. Memory disclosed herein may be any type and size of memory and may be configured to store any type of information desired. To clearly illustrate this interchangeability, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. How such functionality is implemented depends upon the particular application, design choices, and/or design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.
The various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).
The aspects disclosed herein may be embodied in hardware and in instructions that are stored in hardware, and may reside, for example, in Random Access Memory (RAM), flash memory, Read Only Memory (ROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, a hard disk, a removable disk, a CD-ROM, or any other form of non-transitory computer readable medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a remote station. In the alternative, the processor and the storage medium may reside as discrete components in a remote station, base station, or server.
It is also noted that the operational steps described in any of the exemplary aspects herein are described to provide examples and discussion. The operations described may be performed in numerous different sequences other than the illustrated sequences. Furthermore, operations described in a single operational step may actually be performed in a number of different steps. Additionally, one or more operational steps discussed in the exemplary aspects may be combined. It is to be understood that the operational steps illustrated in the flowchart diagrams may be subject to numerous different modifications as will be readily apparent to one of skill in the art. Those of skill in the art will also understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations. Thus, the disclosure is not intended to be limited to the examples and designs described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
